[Bug debugedit/33111] during find-debuginfo/debugedit, "Unhandled relocation 6 at [0] for .debug_info section" for gcc "offload" libraries

[mark at klomp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=33111

--- Comment #8 from Mark Wielaard <mark at klomp dot org> ---
(In reply to Frank Ch. Eigler from comment #7)
> On further checking, it looks like the nvidia stuff is okay with the current
> code.  Archive processing that incurs any errors ($res!=0) causes
> find-debuginfo to preserve the original .a file, so the fake .o files
> (assembler) inside these .a's will be untouched, which is fine.

OK. Does it produce a lot of warning? If so we can add a simple quick check if
the member is an ELF and if not just skip it/put it back untoched?

> Looking in koji over a modern gcc x86-64 build.log shows plenty of warnings
> during brp-strip-lto etc., both before & after these debugedit changes.

Interesting. Does brp-strip-lto use binutils strip or eu-strip?

>  New
> code appears to process the amdgpu dwarf correctly, identifying & packaging
> their source files.

Thanks for testing, I pushed:

commit 2cf8babf67d858c94c627bfc72f8a7036a2c8076
Author: Mark Wielaard <mark@klomp.org>
Date:   Fri Jun 27 15:38:50 2025 +0200

    debugedit: Handle EM_AMDGPU R_AMDGPU_ABS32 relocations

            * tools/debugedit.c (setup_relbuf): Define and handle
            R_AMDGPU_ABS32 for EM_AMDGPU.

    https://sourceware.org/bugzilla/show_bug.cgi?id=33111

    Signed-off-by: Mark Wielaard <mark@klomp.org>

> The only other thing that we should do, for aesthetic reasons, is this,
> which I'll commit as obvious:
> 
> diff --git a/scripts/find-debuginfo.in b/scripts/find-debuginfo.in
> index 1a4f2a0b64d3..b211a3c729c8 100755
> --- a/scripts/find-debuginfo.in
> +++ b/scripts/find-debuginfo.in
> @@ -512,7 +512,7 @@ do_ar_file()
>    # versions to a new archive, in order.
>  
>    # Create empty output .a; mktemp would create a 0-byte file, which ar rv
> doesn't like
> -  ${AR} r "$tmpa" # no members
> +  ${AR} r "$tmpa" 2>/dev/null # no members, suppress "ar: creating foo.a"
> message
>    
>    ${AR} tvO "$f" | while read line; do
>        local pattern='^[rwx-]+ [0-9]+/[0-9]+ +([0-9]+) (.................)
> (.*) (0x[0-9a-f]+)$'
> 
> 
> Otherwise find-debuginfo becomes newly cryptically chatty.

Looks sane yes. Thanks.

-- 
You are receiving this mail because:
You are on the CC list for the bug.