Re: stabs changes for 64 bit targets

[David Taylor <dtaylor at emc dot com>]

nick clifton <nickc@redhat.com> wrote:

> Hi David,

Hello Nick,

> > . 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).

Someone pointed out to me that COFF has a short limit on section names,
so I was going for a short name.  But, I'm concerned about ELF files,
not COFF files.  If that name is okay for COFF, or if COFF did not
support it or used a different name, I'd be okay with any of those.  I
would prefer to support COFF if it is easy; but, ELF is my primary
concern.

> > 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".

I thought that 12 byte STABS was documented somewhere, but I don't
recall where, so maybe it's not.  It appears to be almost documented in
gdb/doc/stabs.texinfo:

    @c FIXME: should refer to external, not internal.
    @example
    struct internal_nlist @{
      unsigned long n_strx;         /* index into string table of name */
      unsigned char n_type;         /* type of symbol */
      unsigned char n_other;        /* misc info (usually empty) */
      unsigned short n_desc;        /* description field */
      bfd_vma n_value;              /* value of symbol */
    @};
    @end example

>    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.

So you want to put yet more knowledge of the debug format into bfd and
the linker?  And if you're linking together 12 byte entries and 16 byte
entries, is that an error?  Or does the linker do the conversion?

I'm okay with it being an error -- increasingly it looks like having
both in the same executable will be hard to support in gdb.  But, my
preference would be to allow it even if some tools require that it be
either one or the other, but not both.

I'd like to keep the linker's knowledge of STABS at a minimum.

> 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...

The assembeler does not know whether the relocated value will fit in 32
bits.  So, if I understand things correctly under your proposal the
linker would have to create the extra section on the fly and then
run-length encode it to boot?

I would like the linker to have as little knowledge of the debug format
as practical.

By choosing a different name, tools that don't know about the new name
typically ignore it.  (One exception is strip -- it looks at the section
attributes, not the names.) If the name is the same and the entries are
larger, then an old gdb tries to interpret the entries -- the result
isn't pretty.