[PATCH] D24706: [ELF] - Partial support of --gdb-index command line option (Part 1).

[David Blaikie via llvm-commits]

On Thu, Oct 6, 2016 at 2:59 AM George Rimar <grimar at accesssoftek.com> wrote:

> > I think Eric's point is that the gdb_index isn't required for or only
> useful for Fission. You could have a gdb_index in a non-fission build (to
> speed up the debugger so it > doesn't have to read all the DWARF at load
> time) or skip the index in a fission build (to reduce executable size at
> the expense of slower gdb startup time)
>
> I see. I did not think about such cases. How will this work ?
>
> 1) I supposed that if gdb see .gdb_index section then it should try to
> locate .dwo files to read info from.
>

The gdb_index doesn't talk about .dwo files, just about compilation units
where certain names/entities are available. If the compilation unit happens
to be a skeleton compilation unit, then the debugger would use the info
found there to discover the .dwo file to load. (but this is an
implementation detail of the CU/skeleton CU/etc - gdb_index is independent
of this detail, it just says which CU to look at)


>      If I have gdb_index in a non-fission executable binary,
> will debugger read gdb_index and start up fast and later read debug info
> from debug sections of executable when will need it ?
>

Right - it'd know which CUs to read, rather than having to read them all to
form its name lookup tables, etc.


>
> 2) If we skip gdb_index in a fission build then there should be very
> little amount of debug information in binary and I supposed that debugger
> will not try to locate .dwo when there is no .gdb_index section. So it
> should be almost useless to debug such build, what I am missing ?
>

The absence of an index would lead GDB to conclude that a name could be in
any CU - so it would look at all of them. If fission was used, then the CUs
would be skeleton CUs and contain the info necessary to find the .dwo file
and the debugger would load those to look for names/entities. This would be
slow because it would load all the .dwos.


>
> And finally, since this file has functionality of creating .gdb_index and
> linker option is also called --gdb-index, what about GdbIndex.cpp/h name ?
>

Seems like a reasonable name.


>
> > It would possibly be better to make the common implementation in LLVM
> more flexible to this use case and more efficient - this could have
> benefits for other LLVM >tools (like LLDB, llvm-dsymutil, and llvm-dwp)
> >If that means splitting up parts of the API so they can be used
> independently, providing ways to provide the contents of sections already
> available through other >means, etc, - those seem like reasonable changes
> to make to the common APIs.
> >
> >- Dave
>
> Yes, probably. But that is also can be separate and large task itself. I
> think we can work on changing common API and switch lld to use it later,
>

If other projects are anything to go by, that rarely, if ever, happens. So
we tend to like to frontload some of this work to avoid divergence which
makes the cost more expensive over time and less likely to be done.

(see LLDB's use of a fork of the LLVM DWARF parsing logic (well, I think
LLVM maybe forked LLDB's, but either way) as a cautionary tale)


> when whole functionality of .gdb_index be landed (since it is probably
> complete in D24267). Then we will have full picture of what exactly we want
> to have from API from linker side and also probably should be able to swich
> step by step and perform benchmarks to compare common llvm implementation
> with what we may have in LLD.
>
> George.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161006/7c786a67/attachment.html>