This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [PATCH] Tiny 64-bit Dwarf2 glitch
- From: Jim Wilson <wilson at redhat dot com>
- To: Jason Eckhardt <jle at owlnet dot rice dot edu>
- Cc: Kevin Buettner <kevinb at redhat dot com>, <binutils at sources dot redhat dot com>
- Date: 25 Jun 2002 17:47:15 -0400
- Subject: Re: [PATCH] Tiny 64-bit Dwarf2 glitch
- References: <Pine.GSO.4.33.0206251554410.29507-100000@forest.owlnet.rice.edu>
> On the 64-bit binaries I'm examining, the first four bytes were 0.
SGI defined and implemented their own 64-bit dwarf2 extensions before there
was a dwarf3 standard for this, and then proposed their extensions to the
committee. This was one of the reasons why SGI started the dwarf3 committee.
In the original SGI proposal, there was no way to tell 32-bit dwarf2 from
64-bit dwarf2. You just had to know which one it was from external info.
On an SGI, I believe this depends on the ABI, e.g. N32 uses 32-bit dwarf2,
N64 uses 64-bit dwarf2. This info could be stuffed in elf header flags
somewhere if necessary.
The committee decided to modify SGI's proposal so that the dwarf3 info was
self-describing. This is partly my fault, as I pointed out the problem with
the SGI proposal. Thus there is the 0xffffffff escape mechanism to specify
a 64-bit dwarf3 file. Since this was agreed on after SGI had already
implemented their proposal, there are SGI systems out there that do not
comply with the dwarf3 standard for 64-bit dwarf3 info.
Jim