This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: stabs changes for 64 bit targets
- From: nick clifton <nickc at redhat dot com>
- To: David Taylor <dtaylor at emc dot com>, binutils at sourceware dot org
- Date: Tue, 14 May 2013 10:18:38 +0100
- Subject: Re: stabs changes for 64 bit targets
- References: <19214 dot 1368457950 at usendtaylorx2l>
Hi David,
. the new section would be named .stab2 instead of .stab
[I wasn't sure what to name it; I didn't want to call it .stab64 as I
could envision someone someday needing to increase the size of the
string table. I don't really care what it is called provided it is
not .stab (backwards compatibility).]
How about: .gnu_stabs ? (Following the general principle of prefix
"gnu" to extensions to parts of existing standards).
Does this sound like a reasonable approach?
Mostly, but...
1. How would this new feature be documented ? Ie there ought to be a
proper document describing the format rather than just a hand waving
"read the code".
2. If you are going to extend the .stab binary format then how about
making a few other improvements too ? Such as including a header that
describes the version of the STABS format being used and the length of
the .stabs entries. That way if some day you need to have 8-byte string
indices for example, you can just bump the version number and increase
the structure size.
An alternative approach, which might occupy less space is to continue to
generate the .stabs entries as before, except that this time the e_value
field will be inaccurate. Then in the .stabs2 (or .gnu_stabs) section
you just have a run-length encoded list of the high parts of the
e_values for each entry. Ie suppose that a .stabs section has 4 entries
and that the e_value fields ought to be:
0x0000880012341234
0x0000880056785678
0x00008800abcdabcd
0xffff000000000000
Then the .stabs section would contain e_values of:
0x12341234
0x56785678
0xabcdabcd
0x00000000
And the ,stabs2 section would contain:
3: 0x00008800
1: 0xffff0000
(The assumption here is that the 64-bit addresses needed for the .stabs
e_value entries are still going to be clumped into 4G pages, so run
length encoding of the high part of the address will save space).
This scheme also has the advantage that the .stabs section would still
be present and could be consumed by old tools that were unaware of the
.stabs2 section, albeit with bogus addresses.
Just a thought...
Cheers
Nick