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.