We (myself and Frank Eigler) think we have found a problem with this
commit:

commit 591cc9fbbfd6d51131c0f1d4a92e7893edcc7a28
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Apr 7 08:18:00 2022 +0200

    gas/Dwarf: record functions
    
    To help tools like addr2line looking up function names, in particular
    when dealing with e.g. PE/COFF binaries (linked from ELF objects), where
    there's no ELF symbol table to fall back to, emit minimalistic
    information for functions marked as such and having their size
    specified.
    ...

The GDB community recently encountered a regression when running the GDB testsuite on recent Fedora rawhide (rolling) releases which use binutils-2.39.  The log file shows this failure:

print /d (int) munmap (4198400, 4096)
Invalid cast.
(gdb) FAIL: gdb.base/break-main-file-remove-fail.exp: cmdline: get integer valueof "(int) munmap (4198400, 4096)"

Running GDB by hand with the testcase binary, I see:

(gdb) ptype munmap
type = void (void)

This explains the reason for the failure: GDB doesn't let us cast a void to an int.

Looking at the output (which ends up in the file "syms") produced by doing "maint print symbols syms" in GDB, I see:

Symtab for file ../sysdeps/unix/syscall-template.S at 0x1149b90
Compilation directory is /usr/src/debug/glibc-2.36.9000-2.fc38.x86_64/misc
Read from object file /lib64/ld-linux-x86-64.so.2 (0xfefbc0)
Language: asm
...
Blockvector:
...
block #000, object at 0x16fd620, 1 syms/buckets in 0x7ffff7feb960..0x7ffff7feb984
...
   void munmap(void); block object 0x16fd3a0, 0x7ffff7feb960..0x7ffff7feb984 section .text

This tells us the name of the object file from where GDB obtained the symbols / debug info as well as reaffirming the fact that GDB thinks that the return type of munmap is 'void'.  (According to its man page, the correct type of munmap should be int munmap(void *addr, size_t length).)

Now, looking at "readelf -w /lib64/ld-linux-x86-64.so.2", we can find the CU and DIE for munmap:

  Compilation Unit @ offset 0x350ac:
   Length:        0x61 (32-bit)
   Version:       5
   Unit Type:     DW_UT_compile (1)
   Abbrev Offset: 0xa21f
   Pointer Size:  8
 <0><350b8>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <350b9>   DW_AT_stmt_list   : 0x1f3fa
    <350bd>   DW_AT_low_pc      : 0x21960
    <350c5>   DW_AT_high_pc     : 36
    <350c6>   DW_AT_name        : (indirect string, offset: 0x186a): ../sysdeps/unix/syscall-template.S
    <350ca>   DW_AT_comp_dir    : (indirect string, offset: 0x26a9): /usr/src/debug/glibc-2.36.9000-2.fc38.x86_64/misc
    <350ce>   DW_AT_producer    : (indirect string, offset: 0x9f1): GNU AS 2.39
    <350d2>   DW_AT_language    : 32769	(MIPS assembler)
...
 <1><350f2>: Abbrev Number: 2 (DW_TAG_subprogram)
    <350f3>   DW_AT_name        : (indirect string, offset: 0x6703): munmap
    <350f7>   DW_AT_external    : 0
    <350f8>   DW_AT_low_pc      : 0x21960
    <35100>   DW_AT_high_pc     : 36

Note that there's no DW_AT_type attribute (which would specify the return type) for the munmap subprogram. As I understand it, this causes the return type to be void.  In section 3.3.2 of the DWARF 5 doc, it says "Debugging information entries for C void functions should not have an attribute for the return type."

However, a potential fix is suggested by section 5.2: "An unspecified (implicit, unknown, ambiguous or nonexistent) type is represented by a debugging information entry with the tag DW_TAG_unspecified_type."

Earlier Fedora releases including Fedora 35, 36, and 37 do not have a munmap subprogram in ld-linux-x86-64.so.2.  For these releases, "ptype munmap" from within GDB shows "type = <unknown return type> ()".  GDB can cast the unknown return type to an int which avoids the "invalid cast" error that we are currently seeing on rawhide.

This problem can be reproduced in a suitable environment by building upstream gdb and then, from within the 'gdb' directory, doing:

make check TESTS=gdb.base/break-main-file-remove-fail.exp

On rawhide, I see the following failures:

FAIL: gdb.base/break-main-file-remove-fail.exp: cmdline: get integer valueof "(int) munmap (4198400, 4096)"
FAIL: gdb.base/break-main-file-remove-fail.exp: file: get integer valueof "(int) munmap (4198400, 4096)"

If you wish to run GDB by hand using the test case for this test, do:

./gdb -q testsuite/outputs/gdb.base/break-main-file-remove-fail/break-main-file-remove-fail 

Then...

(gdb) b start
Breakpoint 1 at 0x40113a: file /ironwood1/sourceware-git/rawhide-master/bld/../../worktree-master/gdb/testsuite/gdb.base/break-main-file-remove-fail.c, line 26.
(gdb) run
Starting program: /mesquite2/sourceware-git/rawhide-master/bld/gdb/testsuite/outputs/gdb.base/break-main-file-remove-fail/break-main-file-remove-fail 

This GDB supports auto-downloading debuginfo from the following URLs:
  <https://debuginfod.fedoraproject.org/>
Enable debuginfod for this session? (y or [n]) n
Debuginfod has been disabled.
To make this setting permanent, add 'set debuginfod enabled off' to .gdbinit.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, start ()
    at /ironwood1/sourceware-git/rawhide-master/bld/../../worktree-master/gdb/testsuite/gdb.base/break-main-file-remove-fail.c:26
26	}
(gdb) ptype munmap
type = void (void)

Regarding debuginfod, I see the same result whether it's enabled or not, but not enabling it makes it clear that the problematic debug info isn't coming from anything downloaded by debuginfod.