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

[George Rimar via llvm-commits]

> 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.
     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 ?

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 ?

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 ?

> 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, 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/a28ddf4f/attachment.html>