[Bug gas/23647] ARM: Incorrect optimization of pseudo instruxtion ldr rx,=0 for -mcpu=cortex-m0plus
https://sourceware.org/bugzilla/show_bug.cgi?id=23647 Johan Dahlberg changed: What|Removed |Added Severity|normal |critical -- 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/23425] unresolved symbol diagnostic ends up calling find_abstract_instance with relocations applied causing spurious 'DWARF error: invalid abstract instance DIE ref'
https://sourceware.org/bugzilla/show_bug.cgi?id=23425 --- Comment #13 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=a4cd947aca23d58966ead843e120f4c19db01030 commit a4cd947aca23d58966ead843e120f4c19db01030 Author: Alan Modra Date: Tue Sep 11 23:50:15 2018 +0930 PR23425, unresolved symbol diagnostic dwarf2.c code reasonably assumes that debug info is local to a file, an assumption now violated by gcc, resulting in "DWARF error: invalid abstract instance DIE ref" or wrong details when attempting to print linker error messages with file, function and line reported. This is because find_abstract_instance is only prepared to handle DW_FORM_ref_addr when the .debug_info section referenced is in the current file. When that isn't the case, relocations to access another file's .debug_info will typically be against a symbol defined at the start of that .debug_info section, plus an addend. Since the dwarf2.c code only considers the current file's debug info, that symbol will be undefined, resolving to zero. In effect the ref_addr will wrongly resolve to the current file's .debug_info. This patch avoids the problem by treating relocations in debug sections against undefined symbols in a similar manner to the way relocations against symbols defined in discarded sections are resolved. They result in a zero value (except in .debug_ranges) regardless of the addend. PR 23425 * reloc.c (bfd_generic_get_relocated_section_contents): Zero reloc fields in debug sections when reloc is against an undefined symbol and called from bfd_simple_get_relocated_section_contents or similar. * dwarf2.c (find_abstract_instance): Return true for zero offset DW_FORM_ref_addr without returning values. -- 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 binutils/23633] objcopy Segmentation fault
https://sourceware.org/bugzilla/show_bug.cgi?id=23633 --- Comment #6 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=1fcd7e871c38ac1049dd5d5509ea1f11a456bf16 commit 1fcd7e871c38ac1049dd5d5509ea1f11a456bf16 Author: Alan Modra Date: Fri Sep 14 19:20:06 2018 +0930 PR23633 testcase fix PR binutils/23633 * testsuite/binutils-all/pr23633.d: Don't fail when assembler generates sections other than .text. -- 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 binutils/23655] New: Wrong disassembler output for EVEX.W instructions in 32-bit
https://sourceware.org/bugzilla/show_bug.cgi?id=23655
Bug ID: 23655
Summary: Wrong disassembler output for EVEX.W instructions in
32-bit
Product: binutils
Version: 2.32 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
Target: i386
[hjl@gnu-cfl-1 testsuite]$ cat 2.s
.text
.byte 0x62, 0xf1, 0xd6, 0x38, 0x2a, 0xf0
[hjl@gnu-cfl-1 testsuite]$ as --32 -o 2.o 2.s
[hjl@gnu-cfl-1 testsuite]$ objdump -dw 2.o
2.o: file format elf32-i386
Disassembly of section .text:
<.text>:
0: 62 f1 d6 38 2a f0 vcvtsi2ss %rax,{rd-sae},%xmm5,%xmm6
Wrong.
[hjl@gnu-cfl-1 testsuite]$
--
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/23658] New: Improve PT_NOTE segment creation
https://sourceware.org/bugzilla/show_bug.cgi?id=23658 Bug ID: 23658 Summary: Improve PT_NOTE segment creation Product: binutils Version: 2.32 (HEAD) Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: hjl.tools at gmail dot com Target Milestone: --- [hjl@gnu-cfl-1 note]$ cat x.s .text .globl _start .type _start, @function _start: ret .section ".note.1", "a" .p2align 3 .long 1f - 0f /* name length. */ .long 3f - 1f /* data length. */ .long 12345/* note type. */ 0: .asciz "GNU"/* vendor name. */ 1: .p2align 3 .long 0 /* pr_type. */ .long 5f - 4f /* pr_datasz. */ 4: .zero 0x10 5: .p2align 3 3: [hjl@gnu-cfl-1 note]$ cat y.s .section ".note.2", "a" .p2align 2 .long 1f - 0f /* name length. */ .long 3f - 1f /* data length. */ .long 12345/* note type. */ 0: .asciz "GNU"/* vendor name. */ 1: .p2align 2 .long 0 /* pr_type. */ .long 5f - 4f /* pr_datasz. */ 4: .zero 0x10 5: .p2align 2 3: [hjl@gnu-cfl-1 note]$ cat z.s .section ".note.3", "a" .p2align 2 .long 1f - 0f /* name length. */ .long 3f - 1f /* data length. */ .long 12345/* note type. */ 0: .asciz "GNU"/* vendor name. */ 1: .p2align 2 .long 0 /* pr_type. */ .long 5f - 4f /* pr_datasz. */ 4: .zero 0x10 5: .p2align 2 3: [hjl@gnu-cfl-1 note]$ make as -mx86-used-note=yes -o y.o y.s as -mx86-used-note=yes -o x.o x.s as -mx86-used-note=yes -o z.o z.s ./ld -z noseparate-code --build-id -o x y.o x.o z.o readelf -lW x Elf file type is EXEC (Executable file) Entry point 0x400224 There are 5 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x00 0x0040 0x0040 0x000225 0x000225 R E 0x1000 NOTE 0x000158 0x00400158 0x00400158 0x28 0x28 R 0x4 NOTE 0x000180 0x00400180 0x00400180 0x30 0x30 R 0x8 NOTE 0x0001b0 0x004001b0 0x004001b0 0x28 0x28 R 0x8 NOTE 0x0001d8 0x004001d8 0x004001d8 0x4c 0x4c R 0x4 Section to Segment mapping: Segment Sections... 00 .note.2 .note.gnu.property .note.1 .note.3 .note.gnu.build-id .text 01 .note.2 02 .note.gnu.property 03 .note.1 04 .note.3 .note.gnu.build-id [hjl@gnu-cfl-1 note]$ We can create just 2 PT_NOTE segments, instead of 4. -- 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 binutils/23655] Wrong disassembler output for EVEX.W instructions in 32-bit
https://sourceware.org/bugzilla/show_bug.cgi?id=23655 --- Comment #1 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=d20dee9efad3c23c9098f03ac785037572258483 commit d20dee9efad3c23c9098f03ac785037572258483 Author: H.J. Lu Date: Fri Sep 14 10:49:43 2018 -0700 x86: Properly decode EVEX.W in vcvt[u]si2s[sd] in 32-bit mode Update x86 disassembler to ignore the EVEX.W bit in EVEX vcvt[u]si2s[sd] instructions in 32-bit mode. gas/ PR binutils/23655 * testsuite/gas/i386/evex.d: New file. * testsuite/gas/i386/evex.s: Likewise. * testsuite/gas/i386/i386.exp: Run evex. opcodes/ PR binutils/23655 * i386-dis-evex.h (evex_table): Replace Eq with Edqa for vcvtsi2ss%LQ, vcvtsi2sd%LQ, vcvtusi2ss%LQ and vcvtusi2sd%LQ. * i386-dis.c (Edqa): New. (dqa_mode): Likewise. (intel_operand_size): Handle dqa_mode as m_mode. (OP_E_register): Handle dqa_mode as dq_mode. (OP_E_memory): Set shift for dqa_mode based on address_mode. -- 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 binutils/23655] Wrong disassembler output for EVEX.W instructions in 32-bit
https://sourceware.org/bugzilla/show_bug.cgi?id=23655
--- Comment #2 from H.J. Lu ---
[hjl@gnu-4 binutils]$ cat /tmp/1.s
.text
.byte 0x62, 0xf1, 0xd6, 0x38, 0x2a, 0xf0
.text
.byte 0x62, 0xf1, 0xd7, 0x38, 0x2a, 0xf0
.text
.byte 0x62, 0xf1, 0xd6, 0x08, 0x7b, 0xf0
.text
.byte 0x62, 0xf1, 0xd7, 0x08, 0x7b, 0xf0
.text
.byte 0x62, 0xf1, 0xd6, 0x38, 0x7b, 0xf0
.text
.byte 0x62, 0xf1, 0xd7, 0x38, 0x7b, 0xf0
[hjl@gnu-4 binutils]$ as --32 -o 1.o /tmp/1.s
[hjl@gnu-4 binutils]$ ./objdump -dw 1.o
1.o: file format elf32-i386
Disassembly of section .text:
<.text>:
0: 62 f1 d6 38 2a f0 vcvtsi2ss %eax,{rd-sae},%xmm5,%xmm6
6: 62 f1 d7 38 2a f0 vcvtsi2sd %eax,{rd-sae},%xmm5,%xmm6
^^^ No such insn
c: 62 f1 d6 08 7b f0 vcvtusi2ss %eax,%xmm5,%xmm6
12: 62 f1 d7 08 7b f0 vcvtusi2sd %eax,%xmm5,%xmm6
18: 62 f1 d6 38 7b f0 vcvtusi2ss %eax,{rd-sae},%xmm5,%xmm6
1e: 62 f1 d7 38 7b f0 vcvtusi2sd %eax,{rd-sae},%xmm5,%xmm6
No such insn
[hjl@gnu-4 binutils]$
--
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 binutils/23655] Wrong disassembler output for EVEX.W instructions in 32-bit
https://sourceware.org/bugzilla/show_bug.cgi?id=23655 --- Comment #3 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=70df6fc9bc9e114f46532dbe58caa98e495b119c commit 70df6fc9bc9e114f46532dbe58caa98e495b119c Author: H.J. Lu Date: Fri Sep 14 11:25:01 2018 -0700 x86: Handle unsupported static rounding in vcvt[u]si2sd in 32-bit mode Update x86 disassembler to handle the unsupported static rounding in vcvt[u]si2sd in 32-bit mode. gas/ PR binutils/23655 * testsuite/gas/i386/evex.d: Updated. opcodes/ PR binutils/23655 * i386-dis-evex.h: Replace EXxEVexR with EXxEVexR64 for vcvtsi2sd%LQ and vcvtusi2sd%LQ. * i386-dis.c (EXxEVexR64): New. (evex_rounding_64_mode): Likewise. (OP_Rounding): Handle evex_rounding_64_mode. -- 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/23642] Wrong encoding with -mevexwig=1
https://sourceware.org/bugzilla/show_bug.cgi?id=23642 --- Comment #1 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=6865c0435a54e6d5f1fcc5cdcd56895e9a3c5484 commit 6865c0435a54e6d5f1fcc5cdcd56895e9a3c5484 Author: H.J. Lu Date: Fri Sep 14 12:19:58 2018 -0700 x86: Support VEX/EVEX WIG encoding Add VEXWIG, defined as 3, to indicate that the VEX.W/EVEX.W bit is ignored by such VEX/EVEX instructions, aka WIG instructions. Set VexW=3 on VEX/EVEX WIG instructions. Update assembler to check VEXWIG when setting the VEX.W bit. gas/ PR gas/23642 * config/tc-i386.c (build_vex_prefix): Check VEXWIG when setting the VEX.W bit. (build_evex_prefix): Check VEXWIG when setting the EVEX.W bit. opcodes/ PR gas/23642 * i386-opc.h (VEXWIG): New. * i386-opc.tbl: Set VexW=3 on VEX/EVEX WIG instructions. * i386-tbl.h: Regenerated. -- 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/23642] Wrong encoding with -mevexwig=1
https://sourceware.org/bugzilla/show_bug.cgi?id=23642 --- Comment #2 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=606cc04085a08f5e04eda6ef67f516bf81b691a1 commit 606cc04085a08f5e04eda6ef67f516bf81b691a1 Author: H.J. Lu Date: Fri Sep 14 12:21:08 2018 -0700 x86: Check non-WIG EVEX instruction encoding with -mevexwig=1 Verify that -mevexwig=1 has no impact on non-WIG EVEX instruction encoding. PR gas/23642 * testsuite/gas/i386/evex-wig2.d: New file. * testsuite/gas/i386/evex-wig2.s: Likewise. * testsuite/gas/i386/x86-64-evex-wig2.d: Likewise. * testsuite/gas/i386/x86-64-evex-wig2.s: Likewise. * testsuite/gas/i386/i386.exp: Run evex-wig2 and x86-64-evex-wig2. -- 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/21375] MIPS: Non-zero run-time value produced for PIC references to undefined hidden or internal weak symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=21375
--- Comment #3 from cvs-commit at gcc dot gnu.org ---
The master branch has been updated by Maciej W. Rozycki :
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=47275900adcda29161e2853179c1fbde4da4c86a
commit 47275900adcda29161e2853179c1fbde4da4c86a
Author: Maciej W. Rozycki
Date: Fri Sep 14 20:22:56 2018 +0100
PR ld/21375: MIPS: Fix non-zero run-time value for undefined weaks
We have an issue in the MIPS backend, with the handling of undefined
hidden and internal weak symbols. References to such symbols are
supposed to resolve to 0 according to the ELF gABI[1]:
"Unresolved weak symbols have a zero value."
and the 64-bit MIPS psABI[2]:
"If a symbol with one of these [hidden or internal] attributes has no
definition within the executable/DSO being linked, then it must be
resolved to allocated space if common, resolved to zero if weak, or an
error reported otherwise."
however if a GOT relocation is used, then a local GOT entry is created
and used to satisfy the reference. Such an entry is then (in DSO and
PIE binaries) subject to the usual load-time relocation, which means a
non-zero value will be returned if the base address is non-zero. This
will defeat the usual run-time sequence like:
void a (void) __attribute__ ((visibility ("hidden"), weak));
void
x (void)
{
if (a)
a ();
}
This can be reproduced with this simple code:
$ cat libtest.c
extern int a __attribute__ ((visibility ("hidden"), weak));
int *
x (void)
{
return &a;
}
$ cat test.c
int *x (void);
int
main (void)
{
printf ("a: %p\n", x ());
return 0;
}
$ gcc -shared -fPIC -o libtest.so libtest.c
$ gcc -o test test.c -Wl,-rpath,$(pwd) libtest.so
$ ./test
a: 0x77184000
$
The usual approach targets take is making all the steps required to
assign a GOT entry for the symbol referred, and then leave its contents
at zero with no dynamic relocation attached, therefore ensuring that the
value does not change at load time. However this is not going to work
with the implicitly relocated GOT the MIPS psABI specifies[3]:
"The dynamic linker relocates the global offset table by first adding
the difference between the base where the shared object is loaded and
the value of the dynamic tag DT_MIPS_BASE_ADDRESS to all local global
offset table entries."
and we cannot therefore use the local GOT part.
And we cannot offhand use the global part either, as the symbol would
then have to be exported and possibly wrongly preempt symbols in other
modules involved in the dynamic load, because as per the ELF gABI[1] we
are not allowed to enter a hidden or internal symbol into the dynamic
symbol table (and then use its associated GOT entry):
"A hidden symbol contained in a relocatable object must be either
removed or converted to STB_LOCAL binding by the link-editor when the
relocatable object is included in an executable file or shared object."
and:
"An internal symbol contained in a relocatable object must be either
removed or converted to STB_LOCAL binding by the link-editor when the
relocatable object is included in an executable file or shared object."
So we have to choose something else.
Our choice is further limited by the need for the reference associated
with the GOT relocation to stay within the signed 16-bit limit from the
GOT pointer base register, while being compliant with the ELF gABI and
the MIPS psABI. However as Alan Modra has observed[4] one possibility
is to edit (relax) the code such that the GOT reference is removed
altogether.
Based on these observations then modify MIPS BFD linker backend code to:
1. Interpret code associated with GOT relocations and relax the usual LW
or LD instructions into a corresponding immediate load operation that
places the value of 0 in the intended register, while leaving the GOT
entry allocated and initialized as usually.
2. Leave any other instructions associated with GOT relocations in place
and instead redirect the reference to a global GOT entry associated
with a special `__gnu_absolute_zero' symbol created for this purpose,
whose value is 0, SHN_ABS section marks it absolute, binding is
global and export class protected, ensuring that the locally provided
value is always used at load time, and that the value is not
relocated by the dynamic loader.
3. Adjust any high-part GOT relocation used, typically associated with
a LUI instruction, accordingly, so that run-time consistency is
maintained, either by resolving to the original entry if the
instruction associated with the corresponding low-part GOT relocation
has been rela
[Bug ld/21805] MIPS: Dynamic symbol --no-export-dynamic rules not respected for SVR4 executables
https://sourceware.org/bugzilla/show_bug.cgi?id=21805
--- Comment #2 from cvs-commit at gcc dot gnu.org ---
The master branch has been updated by Maciej W. Rozycki :
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=47275900adcda29161e2853179c1fbde4da4c86a
commit 47275900adcda29161e2853179c1fbde4da4c86a
Author: Maciej W. Rozycki
Date: Fri Sep 14 20:22:56 2018 +0100
PR ld/21375: MIPS: Fix non-zero run-time value for undefined weaks
We have an issue in the MIPS backend, with the handling of undefined
hidden and internal weak symbols. References to such symbols are
supposed to resolve to 0 according to the ELF gABI[1]:
"Unresolved weak symbols have a zero value."
and the 64-bit MIPS psABI[2]:
"If a symbol with one of these [hidden or internal] attributes has no
definition within the executable/DSO being linked, then it must be
resolved to allocated space if common, resolved to zero if weak, or an
error reported otherwise."
however if a GOT relocation is used, then a local GOT entry is created
and used to satisfy the reference. Such an entry is then (in DSO and
PIE binaries) subject to the usual load-time relocation, which means a
non-zero value will be returned if the base address is non-zero. This
will defeat the usual run-time sequence like:
void a (void) __attribute__ ((visibility ("hidden"), weak));
void
x (void)
{
if (a)
a ();
}
This can be reproduced with this simple code:
$ cat libtest.c
extern int a __attribute__ ((visibility ("hidden"), weak));
int *
x (void)
{
return &a;
}
$ cat test.c
int *x (void);
int
main (void)
{
printf ("a: %p\n", x ());
return 0;
}
$ gcc -shared -fPIC -o libtest.so libtest.c
$ gcc -o test test.c -Wl,-rpath,$(pwd) libtest.so
$ ./test
a: 0x77184000
$
The usual approach targets take is making all the steps required to
assign a GOT entry for the symbol referred, and then leave its contents
at zero with no dynamic relocation attached, therefore ensuring that the
value does not change at load time. However this is not going to work
with the implicitly relocated GOT the MIPS psABI specifies[3]:
"The dynamic linker relocates the global offset table by first adding
the difference between the base where the shared object is loaded and
the value of the dynamic tag DT_MIPS_BASE_ADDRESS to all local global
offset table entries."
and we cannot therefore use the local GOT part.
And we cannot offhand use the global part either, as the symbol would
then have to be exported and possibly wrongly preempt symbols in other
modules involved in the dynamic load, because as per the ELF gABI[1] we
are not allowed to enter a hidden or internal symbol into the dynamic
symbol table (and then use its associated GOT entry):
"A hidden symbol contained in a relocatable object must be either
removed or converted to STB_LOCAL binding by the link-editor when the
relocatable object is included in an executable file or shared object."
and:
"An internal symbol contained in a relocatable object must be either
removed or converted to STB_LOCAL binding by the link-editor when the
relocatable object is included in an executable file or shared object."
So we have to choose something else.
Our choice is further limited by the need for the reference associated
with the GOT relocation to stay within the signed 16-bit limit from the
GOT pointer base register, while being compliant with the ELF gABI and
the MIPS psABI. However as Alan Modra has observed[4] one possibility
is to edit (relax) the code such that the GOT reference is removed
altogether.
Based on these observations then modify MIPS BFD linker backend code to:
1. Interpret code associated with GOT relocations and relax the usual LW
or LD instructions into a corresponding immediate load operation that
places the value of 0 in the intended register, while leaving the GOT
entry allocated and initialized as usually.
2. Leave any other instructions associated with GOT relocations in place
and instead redirect the reference to a global GOT entry associated
with a special `__gnu_absolute_zero' symbol created for this purpose,
whose value is 0, SHN_ABS section marks it absolute, binding is
global and export class protected, ensuring that the locally provided
value is always used at load time, and that the value is not
relocated by the dynamic loader.
3. Adjust any high-part GOT relocation used, typically associated with
a LUI instruction, accordingly, so that run-time consistency is
maintained, either by resolving to the original entry if the
instruction associated with the corresponding low-part GOT relocation
has been rela
[Bug ld/21375] MIPS: Non-zero run-time value produced for PIC references to undefined hidden or internal weak symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=21375 --- Comment #4 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Maciej W. Rozycki : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=982d0151e9ada98e2b5577f9af797b396e48f815 commit 982d0151e9ada98e2b5577f9af797b396e48f815 Author: Maciej W. Rozycki Date: Fri Sep 14 20:22:57 2018 +0100 PR ld/21375: MIPS: Add test cases for undefined weaks resolving to zero Define a new procedure, `run_mips_undefweak_test', and use it to iterate over several scenarios involving undefined weak symbols resolving to zero, verifying expected regular MIPS, MIPS16 and microMIPS code, GOT and dynamic symbol table generation, as well as the setting of the EI_ABIVERSION field in the ELF file header. In particular ensure that symbol versioning works and that `__gnu_absolute_zero' gets assigned a version (any will do) even if it has not been listed for exportation in a linker version script. ld/ PR ld/21375 * testsuite/ld-mips-elf/pr21375-abi.hd: New test. * testsuite/ld-mips-elf/pr21375-noabi.hd: New test. * testsuite/ld-mips-elf/pr21375.dd: New test. * testsuite/ld-mips-elf/pr21375h.dd: New test. * testsuite/ld-mips-elf/pr21375p.dd: New test. * testsuite/ld-mips-elf/pr21375ph.dd: New test. * testsuite/ld-mips-elf/pr21375s.dd: New test. * testsuite/ld-mips-elf/pr21375s-n32.dd: New test. * testsuite/ld-mips-elf/pr21375s-n64.dd: New test. * testsuite/ld-mips-elf/pr21375sh.dd: New test. * testsuite/ld-mips-elf/pr21375sh-n32.dd: New test. * testsuite/ld-mips-elf/pr21375sh-n64.dd: New test. * testsuite/ld-mips-elf/pr21375shg.dd: New test. * testsuite/ld-mips-elf/pr21375sx.dd: New test. * testsuite/ld-mips-elf/pr21375sxh.dd: New test. * testsuite/ld-mips-elf/pr21375sm16.dd: New test. * testsuite/ld-mips-elf/pr21375sm16h.dd: New test. * testsuite/ld-mips-elf/pr21375su.dd: New test. * testsuite/ld-mips-elf/pr21375su-n32.dd: New test. * testsuite/ld-mips-elf/pr21375su-n64.dd: New test. * testsuite/ld-mips-elf/pr21375suh.dd: New test. * testsuite/ld-mips-elf/pr21375suh-n32.dd: New test. * testsuite/ld-mips-elf/pr21375suh-n64.dd: New test. * testsuite/ld-mips-elf/pr21375sux.dd: New test. * testsuite/ld-mips-elf/pr21375suxh.dd: New test. * testsuite/ld-mips-elf/pr21375.gd: New test. * testsuite/ld-mips-elf/pr21375h.gd: New test. * testsuite/ld-mips-elf/pr21375p.gd: New test. * testsuite/ld-mips-elf/pr21375ph.gd: New test. * testsuite/ld-mips-elf/pr21375s.gd: New test. * testsuite/ld-mips-elf/pr21375s-n32.gd: New test. * testsuite/ld-mips-elf/pr21375s-n64.gd: New test. * testsuite/ld-mips-elf/pr21375sh.gd: New test. * testsuite/ld-mips-elf/pr21375sh-n32.gd: New test. * testsuite/ld-mips-elf/pr21375sh-n64.gd: New test. * testsuite/ld-mips-elf/pr21375shg.gd: New test. * testsuite/ld-mips-elf/pr21375shl.gd: New test. * testsuite/ld-mips-elf/pr21375shv.gd: New test. * testsuite/ld-mips-elf/pr21375sx.gd: New test. * testsuite/ld-mips-elf/pr21375sxh.gd: New test. * testsuite/ld-mips-elf/pr21375.sd: New test. * testsuite/ld-mips-elf/pr21375-irix.sd: New test. * testsuite/ld-mips-elf/pr21375h.sd: New test. * testsuite/ld-mips-elf/pr21375h-irix.sd: New test. * testsuite/ld-mips-elf/pr21375p.sd: New test. * testsuite/ld-mips-elf/pr21375p-irix.sd: New test. * testsuite/ld-mips-elf/pr21375ph.sd: New test. * testsuite/ld-mips-elf/pr21375ph-irix.sd: New test. * testsuite/ld-mips-elf/pr21375s.sd: New test. * testsuite/ld-mips-elf/pr21375s-irix.sd: New test. * testsuite/ld-mips-elf/pr21375s-n32.sd: New test. * testsuite/ld-mips-elf/pr21375s-n32-irix.sd: New test. * testsuite/ld-mips-elf/pr21375s-n64.sd: New test. * testsuite/ld-mips-elf/pr21375s-n64-irix.sd: New test. * testsuite/ld-mips-elf/pr21375sh.sd: New test. * testsuite/ld-mips-elf/pr21375sh-irix.sd: New test. * testsuite/ld-mips-elf/pr21375sh-n32.sd: New test. * testsuite/ld-mips-elf/pr21375sh-n32-irix.sd: New test. * testsuite/ld-mips-elf/pr21375sh-n64.sd: New test. * testsuite/ld-mips-elf/pr21375sh-n64-irix.sd: New test. * testsuite/ld-mips-elf/pr21375shg.sd: New test. * testsuite/ld-mips-elf/pr21375shg-irix.sd: New test. * testsuite/ld-mips-elf/pr21375shl.sd: New test. * testsuite/ld-mips-elf/pr21375shl-irix.sd: New test. * testsuite/ld-mips-elf/pr21375shv.sd: New test. * testsuite/ld-mips-elf/pr21375shv-irix.sd: New test. * testsuite/ld-mips-elf/pr21375sx.sd: New test. * testsuite/ld-mips-elf/pr21375sx-irix.sd: New t
[Bug ld/21805] MIPS: Dynamic symbol --no-export-dynamic rules not respected for SVR4 executables
https://sourceware.org/bugzilla/show_bug.cgi?id=21805 Bug 21805 depends on bug 21375, which changed state. Bug 21375 Summary: MIPS: Non-zero run-time value produced for PIC references to undefined hidden or internal weak symbols https://sourceware.org/bugzilla/show_bug.cgi?id=21375 What|Removed |Added Status|SUSPENDED |RESOLVED Resolution|--- |FIXED -- 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/21375] MIPS: Non-zero run-time value produced for PIC references to undefined hidden or internal weak symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=21375 Maciej W. Rozycki changed: What|Removed |Added Status|SUSPENDED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Maciej W. Rozycki --- Fix committed, closing bug. -- 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 binutils/23655] Wrong disassembler output for EVEX.W instructions in 32-bit
https://sourceware.org/bugzilla/show_bug.cgi?id=23655 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |2.32 --- Comment #4 from H.J. Lu --- Fixed. -- 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/23642] Wrong encoding with -mevexwig=1
https://sourceware.org/bugzilla/show_bug.cgi?id=23642 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |2.32 --- Comment #3 from H.J. Lu --- Fixed for 2.32. -- 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
c++filt stack overflow bug
Hi There Peng Li at Baidu X-Lab found a stack overflow bug in c++filt of the latest binutils code base, I have confirmed it with address sanitizer. Please use the “c++filt < stack_overflow_input ” to reproduce the bug. If you have any questions, please let me know. Thanks Peng stack_overflow_input Description: stack_overflow_input ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/23659] New: A stack overflow problem for c++filt
https://sourceware.org/bugzilla/show_bug.cgi?id=23659 Bug ID: 23659 Summary: A stack overflow problem for c++filt Product: binutils Version: 2.32 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: poppeter1982 at gmail dot com Target Milestone: --- Created attachment 11248 --> https://sourceware.org/bugzilla/attachment.cgi?id=11248&action=edit The stack overflow poc Hi There Peng Li at Baidu X-Lab found a stack overflow bug in c++filt of the latest binutils code base, I have confirmed it with address sanitizer. Please use the “c++filt < stack_overflow_input ” to reproduce the bug. If you have any questions, please let me know. Please note that I submitted this error through email to bug-binutils@gnu.org, please ignore the previous one. Thanks Peng -- 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
