[Bug gas/23645] New: Backport as .st_ino/.st_dev check to check input and output are different
https://sourceware.org/bugzilla/show_bug.cgi?id=23645 Bug ID: 23645 Summary: Backport as .st_ino/.st_dev check to check input and output are different Product: binutils Version: 2.31 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: romain.geissler at amadeus dot com Target Milestone: --- Hi, Recently the commit: commit 2a50366ded329bfb39d387253450c9d5302c3503 Author: Robert Yang Date: Tue Aug 14 12:22:35 2018 +0100 which was applied to master fixed the problem described in https://sourceware.org/ml/binutils/2018-08/msg00193.html It was reviewed, modified, approved and applied by Nick Clifton here: https://sourceware.org/ml/binutils/2018-08/msg00273.html Since it affects the release 2.31 (I had the issue when using the release branch), can you please backport it to branch 2.31 as well ? Thanks, Romain -- 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 gold/23646] New: gold segfault when using --threads
https://sourceware.org/bugzilla/show_bug.cgi?id=23646 Bug ID: 23646 Summary: gold segfault when using --threads Product: binutils Version: 2.31 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: jeanmichael.celerier at gmail dot com CC: ian at airs dot com Target Milestone: --- Created attachment 11239 --> https://sourceware.org/bugzilla/attachment.cgi?id=11239&action=edit source file which exhibits the problem Repro in attachment. Using "GNU gold (GNU Binutils 2.31.1) 1.16". Build with $ g++ -flto -std=gnu++17 precompiled.cpp -shared -fuse-ld=gold -Wl,--threads -Wl,--thread-count,16 to get a ld segfault. -- 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 gold/23646] gold segfault when using --threads
https://sourceware.org/bugzilla/show_bug.cgi?id=23646 --- Comment #1 from Jean-Michaël Celerier --- Created attachment 11240 --> https://sourceware.org/bugzilla/attachment.cgi?id=11240&action=edit better source file -- 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 gold/23646] gold segfault when using --threads
https://sourceware.org/bugzilla/show_bug.cgi?id=23646
--- Comment #2 from Jean-Michaël Celerier ---
I added a source file where I removed all the code until I didn't get the
segfault anymore. The culprit (code-wise) is the last line (line 67158):
template T handle::cast() const { return
pybind11::cast(*this); }
--
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 gold/23646] gold segfault when using --threads
https://sourceware.org/bugzilla/show_bug.cgi?id=23646 --- Comment #3 from Jean-Michaël Celerier --- also, if it can be useful : gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --enable-libmpx --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib --disable-werror --enable-checking=release --enable-default-pie --enable-default-ssp --enable-cet=auto Thread model: posix gcc version 8.2.1 20180831 (GCC) -- 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/23647] New: ARM: Incorrect optimization of pseudo instruxtion ldr rx,=0 for -mcpu=cortex-m0plus
https://sourceware.org/bugzilla/show_bug.cgi?id=23647 Bug ID: 23647 Summary: ARM: Incorrect optimization of pseudo instruxtion ldr rx,=0 for -mcpu=cortex-m0plus Product: binutils Version: 2.30 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: johan.dahlberg at electrumab dot se Target Milestone: --- Hello, When the startup assembly code for the NXP S32K116 processor is assembled with gas bundled with gcc versions 6 and 7, the "ldr rx,=0" pseudo instruction is incorrectly optimized into an invalid instruction for this CPU, "mov.w rx,#0" Source code: Reset_Handler: cpsid i /* Mask interrupts */ /* Init the rest of the registers */ ldr r1,=0 ldr r2,=0 ldr r3,=0 ... Gas/Gcc version 6 and 7 generate the mov.w instruction, which does not exist in the Cortex M0+ architecture. Below is the disassembled code for gas/gcc version 7 (GNU assembler (GNU Tools for Arm Embedded Processors 7-2018-q2-update) 2.30.0.20180329): : 0: b672cpsid i 2: f04f 0100 mov.w r1, #0 6: f04f 0200 mov.w r2, #0 a: f04f 0300 mov.w r3, #0 Gas/Gcc version 5 correctly generates the movs instruction: : 0: b672cpsid i 2: 2100movsr1, #0 4: 2200movsr2, #0 6: 2300movsr3, #0 (As reference, the disassembled code for gas/gcc version 4.9, which is less well optimized: : 0: b672cpsid i 2: 4910ldr r1, [pc, #64] ; (44 ) 4: 4a0fldr r2, [pc, #60] ; (44 ) 6: 4b0fldr r3, [pc, #60] ; (44 ) ) Can you please fix this issue? Meanwhile I stick with gas/gcc version 4 or 5... Best regards, /Johan Dahlberg -- 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/23648] New: Symbols based on MEMORY regions confuse --gc-sections.
https://sourceware.org/bugzilla/show_bug.cgi?id=23648
Bug ID: 23648
Summary: Symbols based on MEMORY regions confuse --gc-sections.
Product: binutils
Version: 2.32 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: nbowler at draconx dot ca
Target Milestone: ---
It seems that ld's --gc-sections feature can get confused by the
MEMORY command.
It is possible to define symbols that depend on the memory regions in a
linker script. The --gc-sections function appears to discard sections
as if the MEMORY command was omitted from the linker script.
If removing the MEMORY command affects which sections get referenced,
this means --gc-sections will discard sections that are actually needed
by the link. The results are obviously not good.
For example, consider the following linker script:
% cat >test.ld <<'EOF'
MEMORY { code : ORIGIN = 0, LENGTH = 8M }
SECTIONS {
ENTRY(entry)
.text 1M : { *(.text*) } >code
}
foo = LENGTH(code) > 32M ? test0 : test1;
EOF
And a C source file that uses the linker-defined "foo" like this:
% cat >test.c <<'EOF'
void test0(void) { }
void test1(void) { }
void entry(void)
{
extern void foo(void);
foo();
}
EOF
Compiled like this:
% gcc -ffunction-sections -c test.c
The intention of the example is to call one or the other function based
on the link-time MEMORY configuration. This works fine normally:
% ld -Ttest.ld test.o
% readelf -Ws a.out
[...]
6: 0017 7 FUNCGLOBAL DEFAULT1 test1
7: 0017 0 FUNCGLOBAL DEFAULT1 foo
8: 0010 7 FUNCGLOBAL DEFAULT1 test0
So foo = test1, as expected since LENGTH(code) is less than 32M.
However, if we add --gc-sections, things go awry:
% ld -Ttest.ld --gc-sections --print-gc-sections test.o
ld: Removing unused section '.text.test1' in file 'test.o'
Uhoh...
% readelf -Ws a.out
[...]
5: 0 FUNCGLOBAL DEFAULT ABS foo
6: 0010 7 FUNCGLOBAL DEFAULT1 test0
So test1 is discarded, the unused test0 is kept, and foo is set to
garbage. The resulting code is correspondingly broken.
Testing suggests that --gc-sections evaluates "foo" as if LENGTH(code)
returned -1, regardless of what is specified in the MEMORY command.
This is equivalent to what you'd get if the MEMORY command was omitted.
This appears to be independent of target, as I tried several targets
(and versions) with identical effect.
--
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 #3 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=508d0c9b5945d30bcf163b9b88213d277949e9a8 commit 508d0c9b5945d30bcf163b9b88213d277949e9a8 Author: Nick Clifton Date: Thu Sep 13 16:14:36 2018 +0100 Fix a use-after-freed error introduced by previous attempt to fix a Coverity scan result. PR 23633 * objcopy.c (add_specific_symbols): Do not free the buffer at the end of the function. -- 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 Nick Clifton changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Nick Clifton --- Hi H.J. Thanks for reporting this bug. The problem was the new call to free() at the end of add_specific_symbols(). I had reviewed the code, and looked at the call to add_specific_symbol, and thought that the buffer would not be used after the function finished. What I failed to notice was that although add_specific_symbol calls htab_find_slot with the INSERT parameter, it also records the name string as a value in the hash table. So I have removed the free() and now everything is working again. Cheers Nick -- 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 #5 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=319dbdfbb78d82470498704bca21729e057464f2 commit 319dbdfbb78d82470498704bca21729e057464f2 Author: H.J. Lu Date: Thu Sep 13 09:09:00 2018 -0700 Add a testcase for PR binutils/23633 PR binutils/23633 * testsuite/binutils-all/objcopy.exp: Run pr23633. * testsuite/binutils-all/pr23633.d: New file. * testsuite/binutils-all/pr23633.list: Likewise. * testsuite/binutils-all/pr23633.s: Likewise. -- 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/23648] Symbols based on MEMORY regions confuse --gc-sections.
https://sourceware.org/bugzilla/show_bug.cgi?id=23648 --- Comment #1 from Nick Bowler --- Created attachment 11243 --> https://sourceware.org/bugzilla/attachment.cgi?id=11243&action=edit Possible patch Simply moving the call to lang_do_memory_regions earlier in lang_process is sufficient to make the example case work as expected. Unsure if this is a good idea though. -- 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/23652] New: addr2line finds and parses external debug information but does not use the result for its output
https://sourceware.org/bugzilla/show_bug.cgi?id=23652 Bug ID: 23652 Summary: addr2line finds and parses external debug information but does not use the result for its output Product: binutils Version: 2.32 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: guillaume at morinfr dot org Target Milestone: --- Created attachment 11244 --> https://sourceware.org/bugzilla/attachment.cgi?id=11244&action=edit patch addr2line calls _bfd_dwarf2_find_nearest_line() which then calls _bfd_dwarf2_slurp_debug_info(). _bfd_dwarf2_slurp_debug_info() diligently finds and parses external debug files if necessary. However the calling function (_bfd_elf_find_nearest_line()) does not pass the resulting dwarf_debug2 stash back to _bfd_elf_find_function() for printing. The attached patch changes that by 1) passing the stash as an new argument bfd_elf_find_function() (dwarf_debug2 is not exposed outside of dwarf2.c so this stays as a void **) 2) looking for the corresponding section in dwarf2_debug if provided I am not familiar with the binutils codebase so it might not be the best (or right) solution in all cases but I hope this helps demonstrate the problem and a potential solution. Thank you! -- 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/23653] New: ld SIGSEGVs when attempts to link sparc object with x86_64 library (--enable-targets=all): assertion fail ../../binutils-gdb/bfd/elfxx-sparc.c:1218
https://sourceware.org/bugzilla/show_bug.cgi?id=23653
Bug ID: 23653
Summary: ld SIGSEGVs when attempts to link sparc object with
x86_64 library (--enable-targets=all): assertion fail
../../binutils-gdb/bfd/elfxx-sparc.c:1218
Product: binutils
Version: 2.32 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: slyfox at inbox dot ru
Target Milestone: ---
Created attachment 11245
--> https://sourceware.org/bugzilla/attachment.cgi?id=11245&action=edit
binutils-multitarget-sparc.tar.gz
Original failure was discovered when cross-compiling lua: build system
accidentally linked sparc objects into x86_64 libc:
$ ${HOME}/dev/git/binutils-gdb-native-all-targets/ld/ld-new --eh-frame-hdr
-m elf_x86_64 -shared -o bug.so.5 bug.o ./libc.so.6 ./crtendS.o
/home/slyfox/dev/git/binutils-gdb-native-all-targets/ld/ld-new: BFD (GNU
Binutils) 2.31.51.20180913 assertion fail
../../binutils-gdb/bfd/elfxx-sparc.c:1218
Segmentation fault (core dumped)
Built binutils from master as:
$ ../binutils-gdb/configure --enable-targets=all --disable-werror
Object files are attached. Note: only bug.o is a sparc object.
$ file bug.o ./libc.so.6 ./crtendS.o
bug.o: ELF 32-bit MSB relocatable, SPARC, version 1 (SYSV), not stripped
./libc.so.6: ELF 64-bit LSB pie executable x86-64, version 1 (GNU/Linux),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux
3.2.0, stripped
./crtendS.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
--
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/23653] ld SIGSEGVs when attempts to link sparc object with x86_64 library (--enable-targets=all): assertion fail ../../binutils-gdb/bfd/elfxx-sparc.c:1218
https://sourceware.org/bugzilla/show_bug.cgi?id=23653
Sergei Trofimovich changed:
What|Removed |Added
Target||sparc-*
Host||x86_64-*
Build||x86_64-*
--- Comment #1 from Sergei Trofimovich ---
Sometimes the crash happens before an assert.
valgrind reports the following first erroneous dereference:
==8230== Invalid read of size 4
==8230==at 0x8F116A: _bfd_sparc_elf_create_dynamic_sections
(elfxx-sparc.c:1223)
==8230==by 0x6922DF: _bfd_elf_link_create_dynamic_sections (elflink.c:362)
==8230==by 0x695401: elf_add_dt_needed_tag (elflink.c:3532)
==8230==by 0x697DAE: elf_link_add_object_symbols (elflink.c:4208)
==8230==by 0x697DAE: bfd_elf_link_add_symbols (elflink.c:5723)
==8230==by 0x2CD740: load_symbols (ldlang.c:2881)
==8230==by 0x2CE184: open_input_bfds (ldlang.c:3330)
==8230==by 0x2D0410: lang_process (ldlang.c:7182)
==8230==by 0x2BE3C6: main (ldmain.c:438)
Which is:
bfd_boolean
_bfd_sparc_elf_create_dynamic_sections (bfd *dynobj,
struct bfd_link_info *info)
{
struct _bfd_sparc_elf_link_hash_table *htab;
htab = _bfd_sparc_elf_hash_table (info);
/*1218:*/ BFD_ASSERT (htab != NULL);
if (!_bfd_elf_create_dynamic_sections (dynobj, info))
return FALSE;
/*1223:*/ if (htab->is_vxworks)
--
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
