1485556 - Linux clang + lld builds have a busted .gnu_debuglink

Status: RESOLVED FIXED

(Firefox Build System :: General, enhancement)

Description

[Mike Hommey [:glandium]]

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.

Comment 1

[Mike Hommey [:glandium]]

This happens with lld without lto.

Comment 2

[Mike Hommey [:glandium]]

This could very well be related to bug 1482268

Comment 3

[Mike Hommey [:glandium]]

Turns out both are caused by the same invocation of objcopy in symbolstore.py.

Comment 4

[Mike Hommey [:glandium]]

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.

Comment 5

[Mike Hommey [:glandium]]

Attachment: Bug 1485556 - Remove .gnu_debuglink sections before adding ours.

Comment 6

[(not currently active) Ted Mielczarek]

(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 7

[Nathan Froyd [:froydnj]]

Comment on attachment 9004815 [details]
Bug 1485556 - Remove .gnu_debuglink sections before adding ours.

Nathan Froyd [:froydnj] has approved the revision.

Comment 8

[Mike Hommey [:glandium]]

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

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/60c831f89f87
Remove .gnu_debuglink sections before adding ours. r=froydnj

Comment 10

[Arthur Iakab [arthur_iakab]]

https://hg.mozilla.org/mozilla-central/rev/60c831f89f87

Comment 11

[Thomas Deutschmann]

FYI: Firefox ESR 78 has same problem, .gnu_debuglink is broken when firefox was compiled with clang (no LTO):

readelf --string-dump=.gnu_debuglink /usr/lib64/firefox/firefox
String dump of section '.gnu_debuglink':
  [     0]  Scrt1.o.debug
  [    13]  pcrti.o.debug
  [    28]  crtbeginS.o.debug
  [    40]  crtendS.o.debug
  [    51]  ;Pcrtn.o.debug
  [    64]  6

.gnu_debuglink is fine when using GCC.