Subject: re: Enabling separate debug symbol support for gdb6
To: David Laight <david@l8s.co.uk>
From: matthew green <mrg@eterna.com.au>
List: tech-toolchain
Date: 07/22/2006 06:07:28
And for precisely the same reason that the decision was made to leave
the files unstripped in the first place.
Remember we don't compile stuff with -g, to the symbol table is just
the names of all the functions and data.
i think luke knows exactly why that was done, and what it means.
Although the symbol table remains in the disk file, it isn't in a part
of the file that gets loaded into memory. So splitting the information
into 2 files is just a complete waste of inodes and an extra relationship
that can easily get out of step.
Spliting out the main symbols will leave is in the state that M$ gets into,
where you don't have the .pdb files so can't even get a stack traceback
containing the names of global symbols.
a bunch of folks won't want to install the debug symbols. they're
likely to be at least as large as the rest of the system. are you
going to supply debug & non-debug versions of everything for binary
installs? if not, what will people who don't want them do? eg, what
use are they on a system i don't install the 'comp' set on normally?
i can see the "gets out of sync" argument but i don't find it very
compelling.
You also want to read the discussions about the .eh_frame section in
amd64 binaries - the difficulty in removing it is partially based on
the fact that (excpet for kernels) it is almost never loaded into memory.
this seems entirely irrelevant.
.mrg.