[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