Re: stabs changes for 64 bit targets

[David Taylor <dtaylor at emc dot com>]

Steven Bosscher <stevenb.gcc@gmail.com> wrote:

> On Tue, 14 May 2013 10:38:02 -0400, David Taylor wrote:
> > There are other reasons besides the DWARF verboseness, but they are
> > solvable.  The verboseness (over 10x increase in the size of the elf
> > file) is a show stopper.
> 
> People keep saying that here from time to time. You said it earlier
> this year, but despite trying quite hard I've never been able to
> reproduce such horrible reasons anywhere. I sent you some results of
> my tests, see http://gcc.gnu.org/ml/gcc/2013-01/msg00142.html and the
> whole discussion surrounding it, but you did not reply.

I remember replying to several messages on the subject from various
people.

As I recall, the problem is largely gone in 4.7 -- it was an earlier
version that had the big big problem.

Prior to 4.7, DWARF at level 3 verboseness (i.e., turn on emitting
macros), stores each macro separately rather than in a string table.
Non macro strings are in a string table, but not macros.  With STABS, at
-g3 (store macros -- local extension, posted years ago, but never
accepted / merged) all the strings go into the string table with each
string appearing just once.

I learned after the discussion had died out that the bulk of the
increase was due to the macros.  If I recall correctly, without macros
the increase was more like 20-30%.  I might be remembering the
percentage wrong, but I do remember that DWARF was still bigger than
STABS.

Being able to expand macros in the debugger is important to some of our
users, so I'm not willing to turn that off.

Once 4.8.1 comes out I'm willing to revisit the question of possibly
switching to DWARF and trying to convince by boss and his boss that we
should switch.  But, not now.

> I really don't think further changes to the stabs support should be
> made at this point, other than a full re-write to mimic the DWARF
> model of representing the debug info internally somehow and only emit
> it at the end. That would make it compatible again with PCH and LTO,
> and would *finally* make the front ends not dependent on asm target
> hooks/macros. It's even been suggested to internally represent
> everything as DWARF and to write a dwarf-to-stabs debug emitter.
> 
> Ciao!
> Steven

>From a format perspective, the 12 bytes -> 16 bytes change is fairly
minor.  When fetching / storing an entry, the meaning / interpretation
of the entry is the same except for the size of the address field -- 4
bytes vs 8 bytes.

I could argue that for the x86-64, for anything other than small memory
model, STABS should have had 8 bytes for the address field all along.
But, its been 4 bytes for years and I would like to maintain backwards
compatibility...

So, I think that the cleanest backwards compatible solution is to put
the STABS with a bigger address field into a different section.

I would be agreeable to using the same section name as currently and
putting the information into the zeroth entry if we can achieve
consensus on what it should be.

On the other hand, if the consensus is that there should be no changes
to STABS, then when we finish our changes I won't bother posting the
changes.