Bug 1922707

Suggestion in https://bugzilla.redhat.com/show_bug.cgi?id=1922698#c3 that these might apply to this problem:


commit 9e42b97628f96d8c7f59890e368ddf3a0bd8c811
Author: Fangrui Song <maskray>
Date:   Mon Jan 25 11:35:57 2021 +0000

    Add some more DWARF-5 sections

commit b8df69003de5c662fab94d10af3ad335909fa5bf
Author: Nick Clifton <nickc>
Date:   Mon Jan 25 11:20:20 2021 +0000

    Update linker scripts with the names of new DWARF-5 debug sections.

Fixed in binutils-2.35.1-29.fc34

Installed binutils-2.35.1-29.fc34 to x86_64 rawhide.

still getting same errors.

(In reply to gmgunter from comment #3)
> Installed binutils-2.35.1-29.fc34 to x86_64 rawhide.
> still getting same errors.

Can you point me at a build with these messages ?

The 2.35.1-29 linker definitely has those sections added to its linker scripts, so either a different linker is being used, or else a kernel specific linker script is being provided on the command line.

Sorry, I lost my borken state.

I was trying to compile https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/snapshot/linux-master.tar.gz snapshot retrieved at this time:
-rw-r--r--. 1 user user 189220557 2021-02-01 09:20:47.066486215 +0000 Downloads/linux-master.tar.gz

I put it at https://transfer.sh/10FYBe/linux-master.tar.gz and it should be there for 2 weeks.

I had the system updated to fedora rawhide + binutils-2.35.1-29.fc34 when these issues were present.

Unfortunately, I needed a stable system, since I was in the middle of some homework on this notebook, and intel i915 video drivers have had an intermittent gpu hang for over a year now which always crashes my gnome frame buffers. I have worked around it by using my nvidia discreet card as primary, But, the rawhide kernel doesn't allow non-gpl symbols and my nvidia kmod wouldnt compile, so I was trying to compile a "release" non debugging variety of the kernel...

Anyways, I got frustrated and I regressed my system to 33 with dnf distro-sync, then did dnf builddep kernel.spec --releasever=rawhide && dnf install ./binutils-2.35.1-29.fc34 --releasever=rawhide...

Now it compiles without throwing those messages.

That's the good news.  The bad news is it may raise it's head again at some point.  If it does for me I'll let you know.  *shrug*

Ah.  I got it to fail again.  I was quite tired and now realize was redirecting my warning messages in my make output and that's why it wasnt going to the screen... silly me.

From my log:

...
die__process_function: DW_TAG_INVALID (0x48) @ <0x3f8d> not handled!
die__process_inline_expansion: DW_TAG_INVALID (0x48) @ <0x41a3> not handled!
die__process_function: DW_TAG_INVALID (0x48) @ <0x41b9> not handled!
die__process_function: DW_TAG_INVALID (0x48) @ <0x41d8> not handled!
die__process_function: DW_TAG_INVALID (0x48) @ <0x41f7> not handled!
die__process_function: DW_TAG_INVALID (0x48) @ <0x4204> not handled!
die__process_function: DW_TAG_INVALID (0x48) @ <0x421c> not handled!
die__process_function: DW_TAG_INVALID (0x48) @ <0x422b> not handled!
die__process_function: DW_TAG_INVALID (0x48) @ <0x4238> not handled!
DW_AT_<0x88>=0x21
DW_AT_<0x88>=0x21
DW_AT_<0x88>=0x21
DW_AT_<0xb>=0x21
DW_AT_<0xb>=0x21
...

(In reply to gmgunter from comment #6)
> Ah.  I got it to fail again.  I was quite tired and now realize was
> redirecting my warning messages in my make output and that's why it wasnt
> going to the screen... silly me.
> 
> From my log:
> 
> ...
> die__process_function: DW_TAG_INVALID (0x48) @ <0x3f8d> not handled!
> die__process_inline_expansion: DW_TAG_INVALID (0x48) @ <0x41a3> not handled!
> die__process_function: DW_TAG_INVALID (0x48) @ <0x41b9> not handled!
> die__process_function: DW_TAG_INVALID (0x48) @ <0x41d8> not handled!
> die__process_function: DW_TAG_INVALID (0x48) @ <0x41f7> not handled!
> die__process_function: DW_TAG_INVALID (0x48) @ <0x4204> not handled!
> die__process_function: DW_TAG_INVALID (0x48) @ <0x421c> not handled!
> die__process_function: DW_TAG_INVALID (0x48) @ <0x422b> not handled!
> die__process_function: DW_TAG_INVALID (0x48) @ <0x4238> not handled!
> DW_AT_<0x88>=0x21
> DW_AT_<0x88>=0x21
> DW_AT_<0x88>=0x21
> DW_AT_<0xb>=0x21
> DW_AT_<0xb>=0x21
> ...

That ^ is a different bug: https://bugzilla.redhat.com/show_bug.cgi?id=1922698
Which has fixes upstream, but no release (in Fedora) yet.

I compiled and installed dwarves from the git.  It looks like the patch was merged already.  Still getting those errors.

I am also getting these:

ld: warning: orphan section `.debug_line_str' from `lib/nlattr.o' being placed in section `.debug_line_str'
ld: warning: orphan section `.debug_loclists' from `lib/atomic64_test.o' being placed in section `.debug_loclists'
ld: warning: orphan section `.debug_rnglists' from `lib/atomic64_test.o' being placed in section `.debug_rnglists'
ld: warning: orphan section `.debug_line_str' from `lib/atomic64_test.o' being placed in section `.debug_line_str'
ld: warning: orphan section `.debug_loclists' from `lib/cpu_rmap.o' being placed in section `.debug_loclists'
ld: warning: orphan section `.debug_rnglists' from `lib/cpu_rmap.o' being placed in section `.debug_rnglists'
ld: warning: orphan section `.debug_line_str' from `lib/cpu_rmap.o' being placed in section `.debug_line_str'
ld: warning: orphan section `.debug_loclists' from `lib/dynamic_queue_limits.o' being placed in section `.debug_loclists'
ld: warning: orphan section `.debug_rnglists' from `lib/dynamic_queue_limits.o' being placed in section `.debug_rnglists'
ld: warning: orphan section `.debug_line_str' from `lib/dynamic_queue_limits.o' being placed in section `.debug_line_str'

and:

ARN: multiple IDs found for 'sock_common': 5206, 410304 - using 5206
WARN: multiple IDs found for 'request_sock': 5264, 410354 - using 5264
WARN: multiple IDs found for 'task_struct': 132, 410466 - using 132
WARN: multiple IDs found for 'file': 440, 410489 - using 440
WARN: multiple IDs found for 'seq_file': 1469, 410529 - using 1469
WARN: multiple IDs found for 'sock': 3159, 410566 - using 3159
WARN: multiple IDs found for 'inode': 698, 410664 - using 698
WARN: multiple IDs found for 'path': 729, 410691 - using 729
WARN: multiple IDs found for 'socket': 4459, 411023 - using 4459
WARN: multiple IDs found for 'sk_buff': 4028, 411031 - using 4028
WARN: multiple IDs found for 'bpf_prog': 3954, 411162 - using 3954

Note: I'm working on adding DWARF v5 support to the Linux kernel.

Specifically, my patches inform the linker via linker script that sections are not orphans to be warned on.

The latest patch set is v7 and has not landed yet.

https://lore.kernel.org/lkml/20210130004401.2528717-1-ndesaulniers@google.com/

BTF has some issues with DWARF v5; I'm meeting tomorrow with folks working on that to understand better.

>BTF has some issues with DWARF v5; I'm meeting tomorrow with folks working on that to understand better.

Possibly related:
https://bugzilla.redhat.com/show_bug.cgi?id=1920857
https://lore.kernel.org/bpf/CAEf4Bza4XQxpS7VTNWGk6Rz-iUwZemF6+iAVBA_yvrWnV0k8Qg@mail.gmail.com/

Hi Nick,

(In reply to Nick Desaulniers from comment #9)
> Note: I'm working on adding DWARF v5 support to the Linux kernel.
> 
> Specifically, my patches inform the linker via linker script that sections
> are not orphans to be warned on.
> 
> The latest patch set is v7 and has not landed yet.
> 
> https://lore.kernel.org/lkml/20210130004401.2528717-1-ndesaulniers@google.
> com/

Also tried to reply to that thread, but I think it would be good to drop trying to tweak which version the compiler emits and simply update the linker scripts so they work when the compiler emits DWARF5. At least as first step. After things work fine with the compiler defaults (which is already DWARF5 for GCC 11) you can try giving the user a choice of overriding the DWARF version/variant.

Thanks,

Mark

Still happens with dwarves-1.20-1.fc34.x86_64, libdwarves1-1.20-1.fc34.x86_64. I've got a complete compile log that shows this, if I should attach it let me know.

(In reply to Chris Murphy from comment #12)
> Still happens with dwarves-1.20-1.fc34.x86_64,
> libdwarves1-1.20-1.fc34.x86_64. I've got a complete compile log that shows
> this, if I should attach it let me know.

Is there a scratch build in Koji that demonstrates this?

(In reply to Chris Murphy from comment #12)
> Still happens with dwarves-1.20-1.fc34.x86_64,
> libdwarves1-1.20-1.fc34.x86_64. I've got a complete compile log that shows
> this, if I should attach it let me know.

That would be nice, or a scratch build in Koji as suggested in Comment 13.

dwarves-1.20 for rawhide, f33, f32 is here:
https://koji.fedoraproject.org/koji/packageinfo?packageID=5540

As for logs compiling the kernel that demonstrate this bug (though built with dwarves 1.19 still)
https://kojipkgs.fedoraproject.org//work/tasks/9580/61319580/build.log

I advise downloading it (130MB) rather than opening it in Firefox - it turns my laptop into a hairdryer. I get the originally reported output still with dwarves-1.20.

Note these are just warnings, the linker does the right thing. The linker just isn't sure that is what you want.
The following patch should quiet the warnings:
https://lore.kernel.org/linux-kbuild/20210205202220.2748551-2-ndesaulniers@google.com/
(not accepted upstream yet)

This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle.
Changing version to 34.

The relevant kernel patch has been accepted by the kbuild maintainer: https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/commit/?h=for-next&id=3c4fa46b30c551b1df2fb1574a684f68bc22067c

It hasn't been sent to mainline yet; I expect it to land within the next week or two as part of the 5.12 merge window.  As soon as it lands in mainline, I'll chase getting it backported to the various branches of the stable tree.

The relevant kernel patch has been merged in the mainline Linux kernel.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3c4fa46b30c551b1df2fb1574a684f68bc22067c

You can cherry pick that for more immediate relief.  I'll chase getting it backported to the stable tree's branches. For distros that don't use mainline or stable trees as a baseline and expect to be able to build with GCC 11 (and the implicit default dwarf version used via -g via CONFIG_DEBUG_INFO), they may wish to cherry pick that patch.

(I don't think I have permission to close this bug, so I would like to appeal to whoever does to consider this bug fixed and close it).