There are problems when using current STABS debug format for 64 bit
targets.
A STABS entry is 12 bytes:
. e_strx (4 bytes)
. e_type (1 byte)
. e_other (1 byte)
. e_desc (2 bytes)
. e_value (4 bytes)
Unless you have an awfully lot of debug information, 4 bytes for a
string table index is fine. But, for 64 bit targets, 4 bytes for an
address is not so good.
Initially we were using the x86-64 small memory model. But we now have
a need to place some data symbols at higher addresses. Doing so and
compiling with debugging turned on causes linkage problems -- with STABS
relocations.
So, we are now looking at 16 byte STABS entries -- increasing the size
of the e_value field from 4 bytes to 8 bytes and leaving the other 4
fields alone.
We want things to be backwards compatible and to have one tool chain
that is caplable of producing / consuming both formats.
We also want the changes to be implemented in such a way that they would
be considered for inclusion in future versions of GCC, BINUTILS, and
GDB.
To that end, our thinking is that:
. GCC would still produce STABS entries as now; but, would also support
a command line switch to tell the assembler that the larger STABS were
wanted.
. 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).]
. if both .stab and .stab2 are present in an executable, they would
share the same string table (unless this proves to be a problem, in
which case the .stab2 string table would be named either .stab2str or
.stabstr2)
. GAS, based on a command line switch would produce either 12 byte or 16
byte STABS.
. OBJDUMP / LD / GDB would look at the section name to determine how to
read the STABS.
I am told that the GCC and BINUTILS changes are done except for the
addition of new tests to the testsuite. The GDB changes have been
started.
Does this sound like a reasonable approach? Is the new section name
okay? Or do people have suggestions for a better name? Anything left
out that needs to be done for the changes to be considered for
inclusion?
EMC has paperwork on file for copyright assignment of past and future
changes to GCC, BINUTILS, and GDB.
David
--
David Taylor
dtay...@emc.com
