[Bug binutils/29819] ld testsuite of --version-script relies on -L option
https://sourceware.org/bugzilla/show_bug.cgi?id=29819 --- Comment #3 from Nick Clifton --- (In reply to Martin Liska from comment #2) > That means my example in comment 0 should fail because 'aaa.map' is in 'aaa' > folder (sorry for the bad names) as -Laaa should be ignored when > --version-script=aaa.map is searched. Or do I miss something? I think that you have missed something. The command succeeds because the -Laaa option lets the linker know that is should search for the aaa.map file in the aaa directory. Maybe this will help: % strace ld [...] -Laaa [...] --version-script=aaa.map >& fred % grep openat fred | grep aaa.map openat(AT_FDCWD, "aaa.map", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "aaa/aaa.map", O_RDONLY) = 3 So the linker tries twice to find the aaa.map file. Once in the current directory and then a second time in the aaa/ directory. The --version-script option tells the linker the name of a version control file that it should use. The -L option provides a directory location where the linker might be able to find the file. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29819] ld testsuite of --version-script relies on -L option
https://sourceware.org/bugzilla/show_bug.cgi?id=29819 Martin Liska changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #4 from Martin Liska --- > A version script does count as a control script in this case, so the -L > option does affect searches for them. Ah, sorry, I wrongly read the aforementioned sentence as "doesn't count" :) So thank you for the clarification. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29843] New: binutils-2.39 ld test failures "ld-aarch64/tls-relax-gdesc-le-now", "BTI PLT with only GNU PROP"
https://sourceware.org/bugzilla/show_bug.cgi?id=29843
Bug ID: 29843
Summary: binutils-2.39 ld test failures
"ld-aarch64/tls-relax-gdesc-le-now", "BTI PLT with
only GNU PROP"
Product: binutils
Version: 2.39
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: dilfridge at gentoo dot org
Target Milestone: ---
On binutils 2.39 (~ release branch as of now), running on aarch64 Gentoo,
we get two ld test failures:
FAIL: ld-aarch64/tls-relax-gdesc-le-now
FAIL: BTI PLT with only GNU PROP
Any ideas what's going on? More info on request.
Test log snippets follow:
/var/tmp/portage/sys-devel/binutils-2.39-r4/work/build/ld/../gas/as-new -o
tmpdir/tls-relax-gdesc-le.o
/var/tmp/portage/sys-devel/binutils-2.39-r4/work/binutils-2.39/ld/testsuite/
ld-aarch64/tls-relax-gdesc-le.s
Executing on host: sh -c
{/var/tmp/portage/sys-devel/binutils-2.39-r4/work/build/ld/../gas/as-new -o
tmpdir/tls-relax-gdesc-le.o /var/tmp/portage/sys-devel/binutils-2.39-r4/work/b
inutils-2.39/ld/testsuite/ld-aarch64/tls-relax-gdesc-le.s 2>&1} /dev/null
dump.tmp (timeout = 300)
spawn [open ...]
./ld-new --hash-style=sysv -z norelro
-L/var/tmp/portage/sys-devel/binutils-2.39-r4/work/binutils-2.39/ld/testsuite/ld-aarch64
-shared -z now -o tmpdir/dump tmpdir/tls-relax-gdesc-l
e.o
Executing on host: sh -c {./ld-new --hash-style=sysv -z norelro
-L/var/tmp/portage/sys-devel/binutils-2.39-r4/work/binutils-2.39/ld/testsuite/ld-aarch64
-shared -z now -o tmpdir/dum
p tmpdir/tls-relax-gdesc-le.o 2>&1} /dev/null dump.tmp (timeout = 300)
spawn [open ...]
/var/tmp/portage/sys-devel/binutils-2.39-r4/work/build/ld/../binutils/readelf
-dr tmpdir/dump > tmpdir/dump.out
Executing on host: sh -c
{/var/tmp/portage/sys-devel/binutils-2.39-r4/work/build/ld/../binutils/readelf
-dr tmpdir/dump > tmpdir/dump.out 2>dump.tmp} /dev/null (timeout = 300)
spawn [open ...]
regexp_diff match failure
regexp "^ 0x.+ \(BIND_NOW\) \s+$"
line " 0x001e (FLAGS) BIND_NOW"
FAIL: ld-aarch64/tls-relax-gdesc-le-now
/var/tmp/portage/sys-devel/binutils-2.39-r4/work/build/ld/../gas/as-new
-mabi=lp64 -defsym __property_bti__=1 -o tmpdir/property-bti-pac1.o
/var/tmp/portage/sys-devel/binutils-2.39-
r4/work/binutils-2.39/ld/testsuite/ld-aarch64/property-bti-pac1.s
Executing on host: sh -c
{/var/tmp/portage/sys-devel/binutils-2.39-r4/work/build/ld/../gas/as-new
-mabi=lp64 -defsym __property_bti__=1 -o tmpdir/property-bti-pac1.o
/var/tmp/portag
e/sys-devel/binutils-2.39-r4/work/binutils-2.39/ld/testsuite/ld-aarch64/property-bti-pac1.s
2>&1} /dev/null dump.tmp (timeout = 300)
spawn [open ...]
./ld-new --hash-style=sysv -z norelro
-L/var/tmp/portage/sys-devel/binutils-2.39-r4/work/binutils-2.39/ld/testsuite/ld-aarch64
-e _start -L./tmpdir -lbti-plt-so -o tmpdir/dump tmpdi
r/property-bti-pac1.o
Executing on host: sh -c {./ld-new --hash-style=sysv -z norelro
-L/var/tmp/portage/sys-devel/binutils-2.39-r4/work/binutils-2.39/ld/testsuite/ld-aarch64
-e _start -L./tmpdir -lbti-p
lt-so -o tmpdir/dump tmpdir/property-bti-pac1.o 2>&1} /dev/null dump.tmp
(timeout = 300)
spawn [open ...]
/var/tmp/portage/sys-devel/binutils-2.39-r4/work/build/ld/../binutils/objdump
-dr -j .plt tmpdir/dump > tmpdir/dump.out
Executing on host: sh -c
{/var/tmp/portage/sys-devel/binutils-2.39-r4/work/build/ld/../binutils/objdump
-dr -j .plt tmpdir/dump > tmpdir/dump.out 2>dump.tmp} /dev/null (timeout = 3
00)
spawn [open ...]
regexp_diff match failure
regexp "^.*:f9421611ldr x17, \[x16, #1064\]$"
line " 40028c: f941fe11ldr x17, [x16, #1016]"
regexp_diff match failure
regexp "^.*:9110a210add x16, x16, #0x428$"
line " 400290: 910fe210add x16, x16, #0x3f8"
regexp_diff match failure
regexp "^.*:f9421a11ldr x17, \[x16, #1072\]$"
line " 4002a8: f9420211ldr x17, [x16, #1024]"
regexp_diff match failure
regexp "^.*:9110c210add x16, x16, #0x430$"
line " 4002ac: 91100210add x16, x16, #0x400"
FAIL: BTI PLT with only GNU PROP
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/29843] binutils-2.39 ld test failures "ld-aarch64/tls-relax-gdesc-le-now", "BTI PLT with only GNU PROP"
https://sourceware.org/bugzilla/show_bug.cgi?id=29843 Andreas K. Huettel changed: What|Removed |Added See Also||https://bugs.gentoo.org/sho ||w_bug.cgi?id=883607 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29843] binutils-2.39 ld test failures "ld-aarch64/tls-relax-gdesc-le-now", "BTI PLT with only GNU PROP"
https://sourceware.org/bugzilla/show_bug.cgi?id=29843 Andreas K. Huettel changed: What|Removed |Added CC||toolchain at gentoo dot org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29843] binutils-2.39 ld test failures "ld-aarch64/tls-relax-gdesc-le-now", "BTI PLT with only GNU PROP"
https://sourceware.org/bugzilla/show_bug.cgi?id=29843 Sam James changed: What|Removed |Added CC||sam at gentoo dot org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29844] New: [2.40 Regression] arch/x86/kernel/signal_64.c:31: Error: register type mismatch for `lar'
https://sourceware.org/bugzilla/show_bug.cgi?id=29844 Bug ID: 29844 Summary: [2.40 Regression] arch/x86/kernel/signal_64.c:31: Error: register type mismatch for `lar' Product: binutils Version: 2.40 (HEAD) Status: NEW Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: hjl.tools at gmail dot com Target Milestone: --- Target: x86-64 The current binutils master failed to build Linux kernel 6.1-rc7: arch/x86/kernel/signal_64.c: Assembler messages: arch/x86/kernel/signal_64.c:31: Error: register type mismatch for `lar' arch/x86/kernel/signal_64.c:31: Error: register type mismatch for `lar' -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29844] [2.40 Regression] arch/x86/kernel/signal_64.c:31: Error: register type mismatch for `lar'
https://sourceware.org/bugzilla/show_bug.cgi?id=29844 --- Comment #1 from H.J. Lu --- [hjl@gnu-tgl-2 tmp]$ gcc -c x.s x.s: Assembler messages: x.s:1: Error: register type mismatch for `lar' [hjl@gnu-tgl-2 tmp]$ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29844] [2.40 Regression] arch/x86/kernel/signal_64.c:31: Error: register type mismatch for `lar'
https://sourceware.org/bugzilla/show_bug.cgi?id=29844 --- Comment #2 from H.J. Lu --- [hjl@gnu-tgl-2 tmp]$ cat x.s lar %dx, %edx [hjl@gnu-tgl-2 tmp]$ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29844] [2.40 Regression] arch/x86/kernel/signal_64.c:31: Error: register type mismatch for `lar'
https://sourceware.org/bugzilla/show_bug.cgi?id=29844 --- Comment #3 from H.J. Lu --- This is introduced by commit c9f5b96bdab031e9520d98e01ee1bef1ffd3b961 Author: Jan Beulich Date: Thu Nov 24 09:34:52 2022 +0100 x86: correct handling of LAR and LSL In Intel64 manual, both LAR and LSL have NOTES: * For all loads (regardless of destination sizing), only bits 16-0 are used. Other bits are ignored. In AMD64 manual, both LAR and LSL have LAR/LSL reg16, reg/mem16 LAR/LSL reg32, reg/mem16 LAR/LSL reg64, reg/mem16 -- You are receiving this mail because: You are on the CC list for the bug.
