Steven Bosscher <stevenb....@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.
