[Bug gas/31396] New: Symbols referenced from ".if"/"==" end up in the symbol table
https://sourceware.org/bugzilla/show_bug.cgi?id=31396 Bug ID: 31396 Summary: Symbols referenced from ".if"/"==" end up in the symbol table Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: palmer at gcc dot gnu.org Target Milestone: --- Nathan and I were playing around with some odd behavior in dav1d and I've managed to reduce the test case down to something small. I'm just not actually sure the behavior is a bug. We were looking at the RISC-V port, but the behavior seems the same on x86 as well: $ cat test.s .text .if undefined == 0 .endif .global main main: $ gcc test.s -o test.o -c $ objdump -dt test.o test.o: file format elf64-x86-64 SYMBOL TABLE: *UND* undefined g .text main The resulting objects link fine, I guess because nothing is actually trying to resolve a reference to the undefined symbol. It just seems a little odd to have something unreferenced and undefined end up in the symbol table. I haven't really spent much time touching these more generic bits of GAS and just grepping for "==" is pretty useless, thus I'm a bit lost here. As far as I can tell this isn't actually causing any adverse effects, but I figured I'd at least file something in case anyone else is interested. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31395] New: Wrong search path for DT_NEEDED libs on FreeBSD under gcc -m32
https://sourceware.org/bugzilla/show_bug.cgi?id=31395
Bug ID: 31395
Summary: Wrong search path for DT_NEEDED libs on FreeBSD under
gcc -m32
Product: binutils
Version: 2.40
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: brooks at freebsd dot org
Target Milestone: ---
When invoked via gcc -m32 on a FreeBSD amd64 system, ld searches for
DT_NEEDED libraries as though it were on an i386 system and thus fails
to find them. (This is likely also true for aarch64 and powerpc64, but
I have not verified this is the case.) I think there is a communication
breakdown between gcc and ld that I'm hoping can be resolved in ld
because we maintain a single binutils package and 9 modern-ish gcc
packages.
On FreeBSD we've recently added a libsys which contains system call
implementations and is linked into libc and libthr/libpthread. This has
caused problems when building 32-bit binaries on 64-bit systems using
gcc -m32 because ld fails to find libsys.so.7 unless it is listed
explicitly on the command line. Confusingly that is true even though
gcc passes -L/usr/lib/../lib32 to ld. I belive this is due to this
logic:
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=ld/ldelf.c;h=04045acbf3dc56947edb15e5818dd5b69fd9;hb=HEAD#l1091
Tracing of the gcc -m32 command performed by configure as part of a
gcc12 multilib build confirms that ld tries a number of locations before
failing to find libsys.so.7 and subsequently encountering unresolved
symbols:
...
82890 ld NAMI "/usr/lib/libsys.so.7"
82890 ld NAMI "/usr/lib/compat/libsys.so.7"
82890 ld NAMI "/usr/local/lib/libsys.so.7"
82890 ld NAMI "/usr/local/lib/compat/pkg/libsys.so.7"
82890 ld NAMI "/usr/local/lib/perl5/5.36/mach/CORE/libsys.so.7"
82890 ld NAMI "/usr/local/i386-portbld-freebsd15.0/lib/libsys.so.7"
82890 ld NAMI "/lib/libsys.so.7"
82890 ld NAMI "/usr/lib/libsys.so.7"
82890 ld NAMI "/usr/local/lib/libsys.so.7"
82890 ld NAMI "/lib/libsys.so.7"
82890 ld NAMI "/usr/lib/libsys.so.7"
82890 ld NAMI "/usr/lib/compat/libsys.so.7"
82890 ld NAMI "/usr/local/lib/libsys.so.7"
82890 ld NAMI "/usr/local/lib/compat/pkg/libsys.so.7"
82890 ld NAMI "/usr/local/lib/perl5/5.36/mach/CORE/libsys.so.7"
82890 ld NAMI "/usr/local/i386-portbld-freebsd15.0/lib/libsys.so.7"
82890 ld NAMI "/lib/libsys.so.7"
82890 ld NAMI "/usr/lib/libsys.so.7"
82890 ld NAMI "/usr/local/lib/libsys.so.7"
...
("/lib/libsys.so.7" is found and opened, but presumably rejected due to
the ABI mismatch.)
Further tracing shows that gcc attempts to communicate the correct paths
via a LIBRARY_PATH variable, but I don't think binutils looks for that
at all:
LIBRARY_PATH=/wrkdirs/usr/ports/lang/gcc12/work/.build/./gcc/32/:/usr/lib/../lib
32/:/wrkdirs/usr/ports/lang/gcc12/work/.build/./gcc/:/usr/local/x86_64-portbld-f
reebsd15.0/bin/:/usr/local/x86_64-portbld-freebsd15.0/lib/:/lib/:/usr/lib/
(The presence of x86_64-portbld-freebsd15.0 suggests that gcc isn't
getting this quite right either...)
It seems like the current model is that ld knows nothing about -m32
which is fine to a point, but seems pretty broken here as at most one of
the searched paths contain libaries of the wrong ABI. I don't know if
ld should be honoring LIBRARY_PATH, searching /usr/lib32 unconditionally
on 32-bit FreeBSD platforms, or something else? It's not really practical
to add -lsys to the command line because that needs to happen places like
inside gcc's multilib configure scripts that use the bootstrapped xgcc.
I'm currently working around this issue by linking libc and libthr for
32-bit compat with --rpath=/usr/lib32, but this seems wrong as I'd
ideally be able to use native i386 binaries to populate /usr/lib32.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gprofng/31390] New: [display html] Undefined subroutine ::hex
https://sourceware.org/bugzilla/show_bug.cgi?id=31390 Bug ID: 31390 Summary: [display html] Undefined subroutine ::hex Product: binutils Version: 2.42 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gprofng Assignee: vladimir.mezentsev at oracle dot com Reporter: fantasquex at gmail dot com Target Milestone: --- I'm using gprofng distributed by ArchLinux at commit `https://sourceware.org/binutils/docs/gprofng.html#Man-page-for-gprofng-display-html`. I encountered an error when using `gprofng display html test.1.er`. ``` Undefined subroutine ::hex called at /usr/bin/gp-display-html line 4059, line 1. ``` test.1.er is created by `gprofng collect app ./a.out`. I'm not quite familiar with Perl or gprofng. I just replace `display text` with `display html` in https://sourceware.org/binutils/docs/gprofng.html#Getting-Started. Any suggestion is welcome. Thanks in advance. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27597] nios: assertion fail in nios2_elf32_install_imm16
https://sourceware.org/bugzilla/show_bug.cgi?id=27597 --- Comment #5 from Giulio Benetti --- Thanks a lot Alan, I will provide backported patches soon for Buildroot toolchains so we can reenable building packages affected by this bug. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27597] nios: assertion fail in nios2_elf32_install_imm16
https://sourceware.org/bugzilla/show_bug.cgi?id=27597 Alan Modra changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |2.43 Status|ASSIGNED|RESOLVED --- Comment #4 from Alan Modra --- Fixed -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27597] nios: assertion fail in nios2_elf32_install_imm16
https://sourceware.org/bugzilla/show_bug.cgi?id=27597 --- Comment #3 from Sourceware Commits --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=900c0f0aa3d78cd9e67ccd26fbc86224cef4c5b1 commit 900c0f0aa3d78cd9e67ccd26fbc86224cef4c5b1 Author: Alan Modra Date: Fri Feb 16 22:33:29 2024 +1030 PR27597, nios: assertion fail in nios2_elf32_install_imm16 The assertion in nios2_elf32_install_imm16 triggers when the PLT is twice the maximum allowable size for a branch from PLTn to reach .PLTresolve, and on no other call to nios2_elf32_install_imm16. That makes the assertion completely useless. We can handle a PIC PLT exceeding 0x8000 in size by bouncing branches that won't reach through previous branches. PR 27597 * elf32-nios2.c (nios2_elf32_install_imm16): Delete BFD_ASSERT. (nios2_build_one_stub): Don't bother masking value passed to nios2_elf32_install_imm16. (nios2_elf32_finish_dynamic_symbol): Likewise. Handle overflow of PLTn branch to .PLTresolve by bouncing through prior branches. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27597] nios: assertion fail in nios2_elf32_install_imm16
https://sourceware.org/bugzilla/show_bug.cgi?id=27597 Alan Modra changed: What|Removed |Added Summary|nios: assertion fail|nios: assertion fail in |elf32-nios2.c:1881 |nios2_elf32_install_imm16 --- Comment #2 from Alan Modra --- Testcase cat > bigplt.c <
