[Bug gas/27753] -mx86-used-note= defaulting to yes regresses
https://sourceware.org/bugzilla/show_bug.cgi?id=27753 --- Comment #2 from Jan Beulich --- (In reply to H.J. Lu from comment #1) > It sounds like .note.gnu.property section is unused. Please pass > -R .note.gnu.property to objcopy to remove it. That's what I'm meaning to do as a workaround, but as per https://lists.xen.org/archives/html/xen-devel/2021-04/msg01002.html there are reservations against this approach. No workaround should have been necessary here in the first place. Perhaps the issue wouldn't have occurred if the section hadn't SHF_ALLOC set. Is there a specific reason for this? The gABI looks to mandate the flag to be clear for SHT_NOTE type sections. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27753] -mx86-used-note= defaulting to yes regresses
https://sourceware.org/bugzilla/show_bug.cgi?id=27753 H.J. Lu changed: What|Removed |Added Resolution|--- |NOTABUG Status|UNCONFIRMED |RESOLVED --- Comment #3 from H.J. Lu --- (In reply to Jan Beulich from comment #2) > (In reply to H.J. Lu from comment #1) > > It sounds like .note.gnu.property section is unused. Please pass > > -R .note.gnu.property to objcopy to remove it. > > That's what I'm meaning to do as a workaround, but as per > > https://lists.xen.org/archives/html/xen-devel/2021-04/msg01002.html > > there are reservations against this approach. No workaround should have been > necessary here in the first place. > > Perhaps the issue wouldn't have occurred if the section hadn't SHF_ALLOC > set. Is there a specific reason for this? The gABI looks to mandate the flag > to be clear for SHT_NOTE type sections. All note sections in Linux binary have SHF_ALLOC: [ 2] .note.gnu.build-id NOTE004001d0 0001d0 24 00 A 0 0 4 [ 3] .note.gnu.property NOTE004001f4 0001f4 34 00 A 0 0 4 [ 4] .note.ABI-tag NOTE00400228 000228 20 00 A 0 0 4 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/21700] powerpc-ibm-aix6.1.0.0 fails with unresolved symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=21700 --- Comment #14 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=c5df7e442e6cdc9303b7373842370d6ee8f67ea5 commit c5df7e442e6cdc9303b7373842370d6ee8f67ea5 Author: Cl?ment Chigot Date: Tue Apr 20 14:40:43 2021 +0100 Rework the R_NEG support on both gas and ld for the PowerPC AIX targets, in order to manage C++ exceptions built with GCC. bfd PR binutils/21700 * reloc.c (BFD_RELOC_PPC_NEG): New relocation. * bfd-in2.h: Regenerate. * libbfd.h: Regenerate. * coff-rs6000.c (_bfd_xcoff_reloc_type_lookup): Add BFD_RELOC_PPC_NEG handler. (xcoff_reloc_type_neg): Correctly substract addend. * coff64-rs6000.c (xcoff64_howto_table): Add R_NEG_32 howto. (xcoff64_rtype2howto): Add handler for R_NEG_32. (xcoff64_reloc_type_lookup): Add BFD_RELOC_PPC_NEG handler. * xcofflink.c (xcoff_need_ldrel_p): Check output section for R_POS-like relocations. New argument added. (xcoff_mark): Adapt to new xcoff_need_ldrel_p argument. (xcoff_link_input_bfd): Likewise. gas * config/tc-ppc.c (ppc_get_csect_to_adjust): New function. (ppc_fix_adjustable): Manage fx_subsy part. (tc_gen_reloc): Create second relocation when both fx_addsy and fx_subsy are provided. * config/tc-ppc.h (RELOC_EXPANSION_POSSIBLE): New define. (MAX_RELOC_EXPANSION): Likewise. (TC_FORCE_RELOCATION_SUB_SAME): Likewise (UNDEFINED_DIFFERENCE_OK): Likewise * testsuite/gas/all/gas.exp: Skip difference between two undefined symbols test. ld * testsuite/ld-powerpc/aix52.exp: Add new test. * testsuite/ld-powerpc/aix-neg-reloc-32.d: New test. * testsuite/ld-powerpc/aix-neg-reloc-64.d: New test. * testsuite/ld-powerpc/aix-neg-reloc.ex: New test. * testsuite/ld-powerpc/aix-neg-reloc.s: New test. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27751] test failure on powerpc-linux-gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=27751 --- Comment #3 from Nick Clifton --- (In reply to Efraim Flashner from comment #2) Hi Efraim, > I then downloaded a fresh copy of binutils-2.36.1 and ran the test suite > for libiberty there using Debian's gcc-10.2.1. > > (ins)efraim@g4:~/workspace/binutils-2.36.1/libiberty$ make check > make[1]: Entering directory > '/home/efraim/workspace/binutils-2.36.1/libiberty/testsuite' > gcc -DHAVE_CONFIG_H -g -O2 -I.. -I./../../include -o test-demangle \ > ./test-demangle.c ../libiberty.a [...] > ./test-demangle < ./rust-demangle-expected > FAIL at line 222, options --format=rust: I tried the same using Fedora's gcc-10.2.1-9.fc32.x86_64: % make check make[1]: Entering directory '/dev/shm/delme/build/libiberty/testsuite' gcc -DHAVE_CONFIG_H -g -O2 -I.. -I../../../binutils-2.36.1/libiberty /testsuite/../../include -o test-demangle \ ../../../binutils-2.36.1/libiberty/testsuite/test-demangle.c ../libiberty.a [...] ./test-demangle < ../../../binutils-2.36.1/libiberty/testsuite/rust-demangle-expected ./test-demangle: 68 tests, 0 failures Maybe it is a host problem. What kind of host machine are you using ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27751] test failure on powerpc-linux-gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=27751 --- Comment #4 from Efraim Flashner --- On Tue, Apr 20, 2021 at 01:55:47PM +, nickc at redhat dot com wrote: > I tried the same using Fedora's gcc-10.2.1-9.fc32.x86_64: > > % make check > make[1]: Entering directory '/dev/shm/delme/build/libiberty/testsuite' > gcc -DHAVE_CONFIG_H -g -O2 -I.. -I../../../binutils-2.36.1/libiberty > /testsuite/../../include -o test-demangle \ >../../../binutils-2.36.1/libiberty/testsuite/test-demangle.c >../libiberty.a > [...] > ./test-demangle < > ../../../binutils-2.36.1/libiberty/testsuite/rust-demangle-expected > ./test-demangle: 68 tests, 0 failures > > Maybe it is a host problem. What kind of host machine are you using ? (ins)efraim@g4:~$ neofetch --stdout efraim@g4 - OS: Debian GNU/Linux 11 (bullseye) ppc Host: PowerBook6,7 Kernel: 5.10.0-4-powerpc Uptime: 24 days, 23 hours, 25 mins Packages: 1779 (dpkg) Shell: bash 5.1.4 Resolution: 1024x768 CPU: 7447A (1) @ 1.420GHz GPU: AMD ATI Mobility Radeon 9550 Memory: 326MiB / 1504MiB I have experimented with pkgsrc on this machine in the past but nothing is sourced in my .bashrc. I have some guile libraries in /usr/local and I'm working on porting Guix but nothing installed from it currently. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27751] test failure on powerpc-linux-gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=27751 --- Comment #5 from Nick Clifton --- (In reply to Efraim Flashner from comment #4) > CPU: 7447A (1) @ 1.420GHz So, a 32-bit powerpc. Maybe this is a 32-bit vs 64-bit problem. Do you have access to any other type of machine that you could use for testing ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27751] test failure on powerpc-linux-gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=27751 --- Comment #6 from Andreas Schwab --- It's most likely an endian bug. The same failure happens on ppc, ppc64, s390x, m68k. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27751] test failure on powerpc-linux-gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=27751
--- Comment #7 from Andreas Schwab ---
This is obvious:
static void
demangle_const_char (struct rust_demangler *rdm)
{
size_t hex_len;
uint64_t value;
//
else if (value > ' ' && value < '~')
/* Rust also considers many non-ASCII codepoints to be printable, but
that logic is not easily ported to C. */
print_str (rdm, (char *) &value, 1);
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/27759] New: heap-buffer-overflow in srec_read_section
https://sourceware.org/bugzilla/show_bug.cgi?id=27759 Bug ID: 27759 Summary: heap-buffer-overflow in srec_read_section Product: binutils Version: 2.36.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: rubycc at gmail dot com Target Milestone: --- Created attachment 13391 --> https://sourceware.org/bugzilla/attachment.cgi?id=13391&action=edit The file that reproduces this problem OS : ubuntu 20.04.2 kernel : gnu/linux 5.8.0-48-generic CPU :　Intel(R) Core(TM) i7-10700 CPU @ 2.90GHz compiler : gcc version 9.3.0 Steps to Reproduce : download the sample from the attachment ~/target/binutils-2.36.1-asan/binutils/objcopy -O tekhex ./sample01 ASan trace: /home/ruby/target/binutils-2.36.1-asan/binutils/objcopy: BFD (GNU Binutils) 2.36.1 assertion fail srec.c:736 = ==1714453==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x604000f8 at pc 0x55e4b9f21206 bp 0x7ffdda381c70 sp 0x7ffdda381c60 READ of size 1 at 0x604000f8 thread T0 #0 0x55e4b9f21205 in srec_read_section /home/ruby/target/binutils-2.36.1-asan/bfd/srec.c:796 #1 0x55e4b9f21205 in srec_get_section_contents /home/ruby/target/binutils-2.36.1-asan/bfd/srec.c:843 #2 0x55e4b9f21205 in srec_get_section_contents /home/ruby/target/binutils-2.36.1-asan/bfd/srec.c:821 #3 0x55e4b9ed02d6 in bfd_get_full_section_contents /home/ruby/target/binutils-2.36.1-asan/bfd/compress.c:288 #4 0x55e4b9e1d8c3 in copy_section /home/ruby/target/binutils-2.36.1-asan/binutils/objcopy.c:4409 #5 0x55e4b9effc9e in bfd_map_over_sections /home/ruby/target/binutils-2.36.1-asan/bfd/section.c:1382 #6 0x55e4b9e28a3e in copy_object /home/ruby/target/binutils-2.36.1-asan/binutils/objcopy.c:3303 #7 0x55e4b9e3303a in copy_file /home/ruby/target/binutils-2.36.1-asan/binutils/objcopy.c:3877 #8 0x55e4b9e0e79a in copy_main /home/ruby/target/binutils-2.36.1-asan/binutils/objcopy.c:5930 #9 0x55e4b9e0e79a in main /home/ruby/target/binutils-2.36.1-asan/binutils/objcopy.c:6057 #10 0x7fd915d4f0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2) #11 0x55e4b9e1489d in _start (/home/ruby/target/binutils-2.36.1-asan/binutils/objcopy+0xb689d) 0x604000f8 is located 0 bytes to the right of 40-byte region [0x604000d0,0x604000f8) allocated by thread T0 here: #0 0x7fd91602dbc8 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8) #1 0x55e4b9ee6dcd in bfd_malloc /home/ruby/target/binutils-2.36.1-asan/bfd/libbfd.c:275 SUMMARY: AddressSanitizer: heap-buffer-overflow /home/ruby/target/binutils-2.36.1-asan/bfd/srec.c:796 in srec_read_section Shadow bytes around the buggy address: [7/36] 0x0c087fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c087fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c087fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c087fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c087fff8000: fa fa 00 00 00 00 01 fa fa fa fd fd fd fd fd fa =>0x0c087fff8010: fa fa fd fd fd fd fd fa fa fa 00 00 00 00 00[fa] 0x0c087fff8020: fa fa 00 00 00 00 00 03 fa fa 00 00 00 00 00 fa 0x0c087fff8030: fa fa 00 00 00 00 00 06 fa fa fd fd fd fd fd fa 0x0c087fff8040: fa fa fd fd fd fd fd fa fa fa 00 00 00 00 00 00 0x0c087fff8050: fa fa fd fd fd fd fd fd fa fa 00 00 00 00 00 05 0x0c087fff8060: fa fa fd fd fd fd fd fa fa fa fd fd fd fd fd fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe Left alloca redzone: ca Right alloca redzone:cb Shadow gap: cc ==1714453==ABORTING It also causes the error at HEAD c5df7e44 ~/binutils-gdb-new/binutils/objcopy -O tekhex ./sample01 /home/ruby/target/binutils-gdb-new-asan/binutils/objcopy: BFD (GNU Binutils) 2.36.50.20210420 assertion fail srec.c:736 [1]1222672 segmentation fault ~/target/binutils-gdb-new/binutils/objcopy -O tekhex ./sample01 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27751] test failure on powerpc-linux-gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=27751 --- Comment #8 from Efraim Flashner --- On Tue, Apr 20, 2021 at 02:38:48PM +, nickc at redhat dot com wrote: > (In reply to Efraim Flashner from comment #4) > > > CPU: 7447A (1) @ 1.420GHz > > So, a 32-bit powerpc. Maybe this is a 32-bit vs 64-bit problem. > > Do you have access to any other type of machine that you could use for > testing? I've run through the build and test suite using Guix on x86_64, aarch64 and ppc64le and on aarch64 on Debian (all passed). I have an RPi-1 floating around somewhere, I found the SD card with Debian armel on it but I'm not sure where the board went off to. I also might still have a 32-bit desktop I haven't powered on in a few years running Debian I can test. -- You are receiving this mail because: You are on the CC list for the bug.
