[Bug binutils/17843] New: GAS 2.24.0 incorrectly rejects a legal asm sequence
https://sourceware.org/bugzilla/show_bug.cgi?id=17843
Bug ID: 17843
Summary: GAS 2.24.0 incorrectly rejects a legal asm sequence
Product: binutils
Version: 2.24
Status: NEW
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: geir at cray dot com
GAS 2.24.0 incorrectly rejects a legal asm sequence:
$ cat test_tls.c
__thread int tls_var;
int get_tls_var() {
return tls_var;
}
$ clang --target=aarch64 -S test_tls.c
$ cat test_tls.s
.text
.file"test_tls.c"
.globlget_tls_var
.align2
.typeget_tls_var,@function
get_tls_var:// @get_tls_var
// BB#0:// %entry
movzx8, #:tprel_g1:tls_var
movkx8, #:tprel_g0_nc:tls_var
mrsx9, TPIDR_EL0
ldr w10, [x9, x8]
mov w0, w10
ret
.Ltmp1:
.sizeget_tls_var, .Ltmp1-get_tls_var
.typetls_var,@object // @tls_var
.section.tbss,"awT",@nobits
.globltls_var
.align2
tls_var:
.word0 // 0x0
.sizetls_var, 4
.ident"clang version 3.5.0 (tags/RELEASE_350/final)"
$ aarch64-linux-gnu-as test_tls.s
test_tls.s: Assembler messages:
test_tls.s:9: Error: the specified relocation type is not allowed for MOVK at
operand 2 -- `movk x8,#:tprel_g0_nc:tls_var'
$
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/17843] GAS 2.24.0 incorrectly rejects a legal asm sequence
https://sourceware.org/bugzilla/show_bug.cgi?id=17843 Geir Johansen changed: What|Removed |Added Component|binutils|gas -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/20614] New: gas missing full operand support for vpbroadcastb and vpbroadcastw instructions
https://sourceware.org/bugzilla/show_bug.cgi?id=20614 Bug ID: 20614 Summary: gas missing full operand support for vpbroadcastb and vpbroadcastw instructions Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: geir at cray dot com Target Milestone: --- This does not assemble with the latest gas from git/master (commit d2dfe70): .text .globl main .p2align6, 0x90 .type main,@function main: vpbroadcastb%al, %ymm0 vpbroadcastw%ax, %ymm1 vpbroadcastb%eax, %ymm2 vpbroadcastw%eax, %ymm3 retq The first two vpbroadcast instructions fail with "invalid operand" while the second two get through. I checked the opcodes table in the latest master binutils and it only supports GR32 and GR64 source registers for these instructions. I see nothing in the Intel documentation that restricts these instructions to only take 32- and 64-bit GPRs. As far as I can tell encodings for 8- and 16-bit GPR sizes are legal. It's certainly possible I missed some subtlety and if so it would be helpful to have a better understanding of why these operand sizes aren't supported. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/22445] New: Error: no such instruction: `vpcmplew
https://sourceware.org/bugzilla/show_bug.cgi?id=22445 Bug ID: 22445 Summary: Error: no such instruction: `vpcmplew Product: binutils Version: 2.21 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: geir at cray dot com Target Milestone: --- The B and W variants of the 'vpcmple' psuedo-op instruction is not supported. The Intel ISA indicate that they should be supported. Test case: $ cat fail.s .file "junk.c" .text .globl foo .type foo, @function foo: .LFB0: .cfi_startproc vpcmplew %ymm0,%ymm1,%k1 ret .cfi_endproc .LFE0: .size foo, .-foo .ident "GCC: (GNU) 7.2.0 20170814 [scrubbed]" .section.note.GNU-stack,"",@progbits $ as --version GNU assembler (GNU Binutils; SUSE Linux Enterprise 12) 2.26.1 Copyright (C) 2015 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `x86_64-suse-linux'. $ as fail.s fail.s: Assembler messages: fail.s:8: Error: no such instruction: `vpcmplew %ymm0,%ymm1,%k1' $ The D and Q variants of this instruction are accepted by GAS. $ cat work.s .file "junk.c" .text .globl foo .type foo, @function foo: .LFB0: .cfi_startproc vpcmpleq %ymm0,%ymm1,%k1 ret .cfi_endproc .LFE0: .size foo, .-foo .ident "GCC: (GNU) 7.2.0 20170814 [scrubbed]" .section.note.GNU-stack,"",@progbits $ as work.s $ -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/24920] New: Executable produces nonsensical error message after statically linking with trying to link in a dynamic library.
https://sourceware.org/bugzilla/show_bug.cgi?id=24920
Bug ID: 24920
Summary: Executable produces nonsensical error message after
statically linking with trying to link in a dynamic
library.
Product: binutils
Version: 2.31
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: geir at cray dot com
Target Milestone: ---
A user that attempts to create a static executable that also links in a dynamic
library will result in an executable that produces a confusing error message.
The error message incorrectly indicates that the executable does not exist.
PLEASE NOTE!: The resolution of the issue should be to not allow the link to
complete without error OR at least produce a better runtime error message.
There is no expectation that statically linking with dynamic libraries should
produce a working executable.
Here is the test case:
$ gcc --version
gcc (GCC) 8.3.0 20190222 (Cray Inc.)
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ ls -l /lib64/libaio.so.1*
lrwxrwxrwx 1 root root 15 May 25 2018 /lib64/libaio.so.1 -> libaio.so.1.0.1
-rwxr-xr-x 1 root root 5608 May 25 2018 /lib64/libaio.so.1.0.1
$ cat hello.c
#include
int main(void)
{
printf("Hello World\n");
return 0;
}
$ gcc -c hello.c
$ gcc -static hello.o -Wl,-Bdynamic /lib64/libaio.so.1
$ ./a.out
-bash: ./a.out: No such file or directory
$ ls -l a.out
-rwxr-xr-x 1 geir compiler 12128 Aug 20 11:22 a.out
$ file a.out
a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked,
interpreter /lib/ld6, for GNU/Linux 3.2.0, with debug_info, not stripped
$
The problem appears to be an issue with 'ld':
$ ld --version
GNU ld (GNU Binutils; SUSE Linux Enterprise 15) 2.31.1.20180828-6.3
Copyright (C) 2018 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
$ /usr/bin/ld -m elf_x86_64 -static /usr/lib/../lib64/crt1.o
/usr/lib/../lib64/crti.o
/opt/gcc/8.3.0/snos/lib/gcc/x86_64-suse-linux/8.3.0/crtbeginT.o
-L/opt/gcc/8.3.0/snos/lib/gcc/x86_64-suse-linux/8.3.0
-L/opt/gcc/8.3.0/snos/lib/gcc/x86_64-suse-linux/8.3.0/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/opt/gcc/8.3.0/snos/lib/gcc/x86_64-suse-linux/8.3.0/../../.. hello.o
--start-group -lgcc -lgcc_eh -lc --end-group
/opt/gcc/8.3.0/snos/lib/gcc/x86_64-suse-linux/8.3.0/crtend.o
/usr/lib/../lib64/crtn.o -Bdynamic /lib64/libaio.so.1
$ ./a.out
-bash: ./a.out: No such file or directory
$
If the '-Bdynamic' option is removed, then an appropriate link time error
is provided:
$ /usr/bin/ld -m elf_x86_64 -static /usr/lib/../lib64/crt1.o
/usr/lib/../lib64/crti.o
/opt/gcc/8.3.0/snos/lib/gcc/x86_64-suse-linux/8.3.0/crtbeginT.o
-L/opt/gcc/8.3.0/snos/lib/gcc/x86_64-suse-linux/8.3.0
-L/opt/gcc/8.3.0/snos/lib/gcc/x86_64-suse-linux/8.3.0/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/opt/gcc/8.3.0/snos/lib/gcc/x86_64-suse-linux/8.3.0/../../.. hello.o
--start-group -lgcc -lgcc_eh -lc --end-group
/opt/gcc/8.3.0/snos/lib/gcc/x86_64-suse-linux/8.3.0/crtend.o
/usr/lib/../lib64/crtn.o /lib64/libaio.so.1
/usr/bin/ld: attempted static link of dynamic object `/lib64/libaio.so.1'
$
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/24920] Executable produces nonsensical error message after statically linking with trying to link in a dynamic library.
https://sourceware.org/bugzilla/show_bug.cgi?id=24920 --- Comment #3 from Geir Johansen --- Problem still occurs with somewhat more recent software: $ gcc --version gcc (GCC) 9.2.0 20190812 (Cray Inc.) Copyright (C) 2019 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ gcc -c hello.c $ ld --version GNU ld (GNU Binutils) 2.32 Copyright (C) 2019 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. $ ld -m elf_x86_64 -static /usr/lib64/crt1.o /usr/lib64/crti.o /opt/gcc/9.2.0/snos/lib/gcc/x86_64-suse-linux/9.2.0/crtbeginT.o -L/opt/gcc/9.2.0/snos/lib/gcc/x86_64-suse-linux/9.2.0 -L/opt/gcc/9.2.0/snos/lib/lib64 hello.o --start-group -lgcc -lgcc_eh -lc --end-group /opt/gcc/9.2.0/snos/lib/gcc/x86_64-suse-linux/9.2.0/crtend.o /usr/lib64/crtn.o -Bdynamic /lib64/libaio.so.1 $ ./a.out -bash: ./a.out: No such file or directory $ file a.out a.out: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld6, for GNU/Linux 3.2.0, with debug_info, not stripped $ ldd a.out linux-vdso.so.1 (0x7ffc5a318000) libaio.so.1 => /lib64/libaio.so.1 (0x7f1372c2c000) libc.so.6 => /lib64/libc.so.6 (0x7f1372872000) /lib/ld64.so.1 => /lib64/ld-linux-x86-64.so.2 (0x7f1372e2e000) $ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/6924] New: ld does not understand DWARF version 3 when trying to get a source line number
Using ld version 2.18 when linking a PGI 7.2-5 compiled program, I see the following dwarf error: $ cat datatypes.module.f90 module datatypes integer, parameter :: short = 1 end module datatypes $ cat main.f90 program TEST use datatypes end program TEST $ pgf90 -Mdwarf3 -g -c datatypes.module.f90 < $ pgf90 -Mdwarf3 -g -c main.f90 $ pgf90 -Mdwarf3 main.o /usr/bin/ld: Dwarf Error: found dwarf version '3', this reader only handles version 2 information. main.o:(.debug_info+0x74): undefined reference to `..Dm_datatypes' $ The "undefined reference" error is a PGI compiler error, so that can be ignored. The message: "Dwarf Error: found dwarf version '3', this reader only handles version 2 information." is occurring when the loader is trying to get the line number for the "undefined reference" error. 'ld' should at least be able to get the source line number for a code in Dwarf 3 format. -- Summary: ld does not understand DWARF version 3 when trying to get a source line number Product: binutils Version: 2.18 Status: NEW Severity: normal Priority: P2 Component: ld AssignedTo: unassigned at sources dot redhat dot com ReportedBy: geir at cray dot com CC: bug-binutils at gnu dot org http://sourceware.org/bugzilla/show_bug.cgi?id=6924 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/3191] Dwarf 2 reader in linker doesn't suppor DW_FORM_ref_addr
-- What|Removed |Added CC||geir at cray dot com http://sourceware.org/bugzilla/show_bug.cgi?id=3191 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11006] New: A "relaxed" link order of libraries is requested for improved compatibilty
The GNU ld linker requires the user to specify libraries after any object
files which use them. For example:
$ cat main.c
void sub();
main() {
sub();
}
$ gcc -c sub.c
$ ar rv libsub.a sub.o
ar: creating libsub.a
a - sub.o
$ gcc -L . -lsub main.c ### FAILS !!!
/tmp/cccN9Qxp.o: In function `main':
main.c:(.text+0xa): undefined reference to `sub'
collect2: ld returned 1 exit status
$ gcc main.c -L . -lsub ### WORKS !!!
$
The linking order requirement is not needed by AIX, so this has been an issue
for users migrating from an AIX system to Linux. This enhancement bug is being
submitted for the benefit of these users.
-
I am aware of the following workaround:
$ gcc -Wl,--start -lsub -L. main.c -Wl,--end
$
--
Summary: A "relaxed" link order of libraries is requested for
improved compatibilty
Product: binutils
Version: 2.16
Status: NEW
Severity: enhancement
Priority: P2
Component: ld
AssignedTo: unassigned at sources dot redhat dot com
ReportedBy: geir at cray dot com
CC: bug-binutils at gnu dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=11006
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
