[PATCH] D61343: [llvm-objcopy] Cache gnu_debuglink's target CRC

MichaƂ Janiszewski via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed May 1 11:30:44 PDT 2019


janisozaur added a comment.

In D61343#1485793 <https://reviews.llvm.org/D61343#1485793>, @jhenderson wrote:

> Whilst I don't necessarily object to this change, I do wonder as to its necessity. Have you seen this as an issue in practice?


Yes. For a given foo.a archive and its debug symbols foo.a.debug, try executing `llvm-objcopy --add-gnu-debuglink=foo.a.debug foo.a`. In my tests with ~130MiB of debug symbols and 300 entries in the archive, it takes about 1 minute 25 seconds to complete without this patch and less than 500ms with this patch, producing SHA1-identical output.

> My understanding of the .gnu_debuglink section is that there should be a single entry in it in an executable, pointing at a single file containing debug information for that executable. Adding the section to relocatable object files (and therefore to archive members) makes no sense, since you don't debug those.

I have not investigated why is it being added to each member of the archive, but I can imagine when you create a static archive, there is no section to place this information and only object files exist which are capable of holding such information. Then, when you link said archive to executable, linker is free to only select and use the object files actually in use, hence each of them should carry relevant information.

You can observe very similar behaviour in GNU binutils' objcopy, where I've filed a similar patch.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61343/new/

https://reviews.llvm.org/D61343





More information about the llvm-commits mailing list