Closed Bug 1485556 Opened Last year Closed Last year

Linux clang + lld builds have a busted .gnu_debuglink

Categories

(Firefox Build System :: General, enhancement)

enhancement
Not set

Tracking

(firefox63 fixed)

RESOLVED FIXED
mozilla63
Tracking Status
firefox63 --- fixed

People

(Reporter: glandium, Assigned: glandium)

References

Details

Attachments

(1 file)

On a build without LTO:

$ objdump -j .gnu_debuglink -s firefox/libnssutil3.so 

firefox/libnssutil3.so:     file format elf64-x86-64

Contents of section .gnu_debuglink:
 0000 6c69626e 73737574 696c332e 736f2e64  libnssutil3.so.d
 0010 62670000 1b5ae9c0                    bg...Z..        

On a build with LTO:

$ firefox/libnssutil3.so:     file format elf64-x86-64

Contents of section .gnu_debuglink:
 0000 63727469 2e6f0000 113b2ab1 6372746e  crti.o...;*.crtn
 0010 2e6f0000 ee4471af                    .o...Dq.
This happens with lld without lto.
Summary: Linux clang + lto builds have a busted .gnu_debuglink → Linux clang + lld builds have a busted .gnu_debuglink
This could very well be related to bug 1482268
Turns out both are caused by the same invocation of objcopy in symbolstore.py.
Status: NEW → RESOLVED
Closed: Last year
Resolution: --- → DUPLICATE
Duplicate of bug: 1482268
Actually, this is going to need some separate handling from bug 1482268.

So, it turns out the .gnu_debuglink with the crt object file references are there from linking. Not sure if it should be, but it is.

llvm-objcopy can deal with the situation, and adds a separate .gnu_debuglink section in that case. I'm not sure how gdb reacts to that, I haven't had the chance to test that yet.

The problem is that llvm-objcopy doesn't support --only-keep-debug to create the separate .dbg files in the first place. (https://reviews.llvm.org/D40523 has not landed)

And a newer binutils objcopy doesn't want to add or change the .gnu_debuglink.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Assignee: nobody → mh+mozilla
(In reply to Mike Hommey [:glandium] from comment #4)
> So, it turns out the .gnu_debuglink with the crt object file references are
> there from linking. Not sure if it should be, but it is.

This seems like unexpected behavior. Should we file a bug upstream on this? I don't know why the CRT object file even has this section in the first place, but preserving it into the final link doesn't seem good.
Comment on attachment 9004815 [details]
Bug 1485556 - Remove .gnu_debuglink sections before adding ours.

Nathan Froyd [:froydnj] has approved the revision.
Attachment #9004815 - Flags: review+
Was going to file an upstream bug, and the possible duplicates thing on their bugzilla found: https://bugs.llvm.org/show_bug.cgi?id=27564
Pushed by mh@glandium.org:
https://hg.mozilla.org/integration/mozilla-inbound/rev/60c831f89f87
Remove .gnu_debuglink sections before adding ours. r=froydnj
https://hg.mozilla.org/mozilla-central/rev/60c831f89f87
Status: REOPENED → RESOLVED
Closed: Last yearLast year
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
You need to log in before you can comment on or make changes to this bug.