This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] Speed up find_pc_section


On Fri, Sep 11, 2009 at 12:53 AM, Tristan Gingold <gingold@adacore.com> wrote:
>>
>> [The separate debuginfo file is thus fundamentally different from the
>> "bunch of .o files with debug info on MacOS", and extending the separate
>> debuginfo to cover MacOS situation (mentioned elsewhere as a possible
>> solution) is (IMHO) the wrong approach.]
>
> Can you elaborate ?
>
> IMHO this is not fundamentally different. ?In both cases, one file contains
> the code and the other/others debug infos.

As I said before, the "primary" and "secondary" objfiles in the
separate debuginfo case have a common ancestor, and are almost like
identical twins: same sections (except for the weird F11 prelinking
case), same symbol tables, same file ELF file type, etc.

That isn't at all the case for MacOS "bunch of .o files" -- now we
have a "pile of parts" and a "completed engine". Certainly the
sections from separate .o files should not appear in the section map;
not sure whether symbols should, but likely not.

It sounds to me as if you'd want to pick up just the debug bits from
*.o, without turning them into full-blown objfiles.

I should mention that on Solaris, Sun cc uses the same trick: leaves
(stabs) debug info in the .o files and doesn't put any of them into
the final linked image (unless '-xs' flag is given on command line).
The name of the object file with debug info is recorded in N_OPT stab
entries in the image, so DBX knows where to find them. It doesn't look
like GDB supports this currently.

Cheers,
-- 
Paul Pluzhnikov


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]