[Bug binutils/27879] stack-buffer-overflow on sysdump
https://sourceware.org/bugzilla/show_bug.cgi?id=27879 Alan Modra changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-05-18 Assignee|unassigned at sourceware dot org |amodra at gmail dot com Status|UNCONFIRMED |ASSIGNED -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27814] objdump crashes when disassembling a non-ELF RISC-V binary
https://sourceware.org/bugzilla/show_bug.cgi?id=27814 Nelson Chu changed: What|Removed |Added CC||nelsonc1225 at sourceware dot org Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Nelson Chu --- Hi Job Noorman, Thanks for reporting this. I have committed this fix, with the name and email from your account. So marked as resolved and fixed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27814] objdump crashes when disassembling a non-ELF RISC-V binary
https://sourceware.org/bugzilla/show_bug.cgi?id=27814 --- Comment #3 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nelson Chu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=113bb7618a4b52c5fc8fdc0e82b2cd9f72471f72 commit 113bb7618a4b52c5fc8fdc0e82b2cd9f72471f72 Author: Job Noorman Date: Tue May 18 08:41:11 2021 +0800 RISC-V: PR27814, Objdump crashes when disassembling a non-ELF RISC-V binary. 2021-05-18 Job Noorman opcodes/ PR 27814 * riscv-dis.c (riscv_get_disassembler): Get elf attributes only for the elf objects. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27879] stack-buffer-overflow on sysdump
https://sourceware.org/bugzilla/show_bug.cgi?id=27879 Shaohua Li changed: What|Removed |Added Summary|stash-buffer-overflow on|stack-buffer-overflow on |sysdump |sysdump -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27879] New: stash-buffer-overflow on sysdump
https://sourceware.org/bugzilla/show_bug.cgi?id=27879 Bug ID: 27879 Summary: stash-buffer-overflow on sysdump Product: binutils Version: 2.37 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: shaohua.li at inf dot ethz.ch Target Milestone: --- Created attachment 13456 --> https://sourceware.org/bugzilla/attachment.cgi?id=13456=edit poc Hi there, I found a stack-buffer-overflow on sysdump with a fuzzer. I attached the poc file. Compiler: clang12 Compile args: -fsanitize=address Reproduce: `sysdump poc` AddressSanitizer output: ==30955==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffeaa74a95f at pc 0x00496b07 bp 0x7ffeaa74a830 sp 0x7ffeaa749ff8 READ of size 255 at 0x7ffeaa74a95f thread T0 #0 0x496b06 in __asan_memcpy (/data/clean/binutils-gdb-asan/binutils/sysdump+0x496b06) #1 0x4d9725 in getBARRAY /data/clean/binutils-gdb-asan/binutils/sysdump.c:146:17 #2 0x4d9725 in sysroff_swap_ob_in /data/clean/binutils-gdb-asan/binutils/./sysroff.c:1296:15 #3 0x4e4839 in getone /data/clean/binutils-gdb-asan/binutils/sysdump.c:419:2 #4 0x4e4839 in module /data/clean/binutils-gdb-asan/binutils/sysdump.c:618:10 #5 0x4e4839 in main /data/clean/binutils-gdb-asan/binutils/sysdump.c:709:3 #6 0x7fd3cf0db0b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16 #7 0x41c4fd in _start (/data/clean/binutils-gdb-asan/binutils/sysdump+0x41c4fd) Address 0x7ffeaa74a95f is located in stack of thread T0 at offset 287 in frame #0 0x4d935f in sysroff_swap_ob_in /data/clean/binutils-gdb-asan/binutils/./sysroff.c:1280 This frame has 2 object(s): [32, 287) 'raw' (line 1281) [352, 356) 'idx' (line 1282) <== Memory access at offset 287 partially underflows this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-overflow (/data/clean/binutils-gdb-asan/binutils/sysdump+0x496b06) in __asan_memcpy Shadow bytes around the buggy address: 0x1000554e14d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000554e14e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000554e14f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000554e1500: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 0x1000554e1510: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x1000554e1520: 00 00 00 00 00 00 00 00 00 00 00[07]f2 f2 f2 f2 0x1000554e1530: f2 f2 f2 f2 04 f3 f3 f3 00 00 00 00 00 00 00 00 0x1000554e1540: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 0x1000554e1550: f8 f2 f8 f2 f8 f2 f8 f2 f8 f2 f8 f8 f8 f8 f8 f8 0x1000554e1560: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 0x1000554e1570: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f2 f2 f2 f2 f2 f2 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 ==30955==ABORTING -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27878] New: [z80-unknown-elf]: ld (hl),<16 bit immediate> should fail assembly
https://sourceware.org/bugzilla/show_bug.cgi?id=27878 Bug ID: 27878 Summary: [z80-unknown-elf]: ld (hl),<16 bit immediate> should fail assembly Product: binutils Version: 2.36.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: petemoore at gmx dot net CC: sergey.belyashov at gmail dot com Target Milestone: --- Target: z80-unknown-elf ``` $ # GAS version $ z80-unknown-elf-as --version GNU assembler (GNU Binutils) 2.36.1 Copyright (C) 2021 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 `z80-unknown-elf'. $ # Sample assembly file $ cat test.asm ld (0x1234), hl ld (hl), 0x1234 $ # Assembly doesn't fail nor warn that a constant is out-of-range, but instead truncates the value 0x1234 to 0x34 $ z80-unknown-elf-as -o test.o test.asm && z80-unknown-elf-objdump -d test.o test.o: file format elf32-z80 Disassembly of section .text: <.text>: 0: 22 34 12ld (0x1234),hl 3: 36 34 ld (hl),0x34 ``` Some Z80 operations support loading a 16 bit value to memory (e.g. ld (nn),hl) but others only support loading 8 bit values (e.g. ld (hl),n). It can be easy to forget when initialising a 16 bit constant value at a fixed address, whether you need a constant address in the instruction and the value in a register, or the address in a register and a constant value in the instruction. The assembler doesn't fail nor throw a warning if you try to load a 16 bit constant value into (hl), but instead silently truncates it to 8 bits. A warning or failure would be desirable for the assembly of _any_ instruction where the immediate constant is out-of-range for the given instruction. I only noticed it so far with the the ld (hl),n instruction, but it would be good to test all instructions that take 8 bit immediates with an out-of-range 16 bit value, to see if any other instructions exhibit the same issue. I'm happy to help with writing tests etc, if I can be given some initial guidance. Many thanks! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27871] ld: Add -Bsymbolic-non-weak-functions which only applies to STB_GLOBAL STT_FUNC
https://sourceware.org/bugzilla/show_bug.cgi?id=27871 Fangrui Song changed: What|Removed |Added Summary|ld: Add |ld: Add |-Bsymbolic-global-functions |-Bsymbolic-non-weak-functio |which only applies to |ns which only applies to |STB_GLOBAL STT_FUNC |STB_GLOBAL STT_FUNC -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27666] ar doesn't create indices on Solaris/sparcv9
https://sourceware.org/bugzilla/show_bug.cgi?id=27666 Nick Clifton changed: What|Removed |Added Assignee|unassigned at sourceware dot org |nickc at redhat dot com Status|NEW |ASSIGNED CC||nickc at redhat dot com --- Comment #2 from Nick Clifton --- Created attachment 13455 --> https://sourceware.org/bugzilla/attachment.cgi?id=13455=edit Proposed patch Hi Rainer, Would you mind trying out the uploaded patch ? I am working on a theory that the real bug is that _bfd_write_archive_contents() is not creating the symbol index. As you noted the call to bfd_check_format() fails, because there are two potential matches. But I do not think that this is grounds for the archiver to decide that there are no objects in the library. Even with this patch applied, most of the linker tests that are failing continue to do so, but I have not yet investigated why. I just wanted to show you my ida, and see if you thought that it might be worth persuing. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
Issue 31242 in oss-fuzz: binutils:fuzz_bfd: Timeout in fuzz_bfd
Updates: Labels: Deadline-Approaching Comment #3 on issue 31242 by sheriffbot: binutils:fuzz_bfd: Timeout in fuzz_bfd https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=31242#c3 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
[Bug binutils/27865] Unsupported name-unmangling for C++20 modules?
https://sourceware.org/bugzilla/show_bug.cgi?id=27865 Nathan Sidwell changed: What|Removed |Added CC||nathan at acm dot org --- Comment #4 from Nathan Sidwell --- The mangling is documented at https://gcc.gnu.org/wiki/cxx-modules?action=AttachFile=view=module-abi-2017-09-01.pdf but be aware that we (clang-devs and I) have been reconsidering the weak ownership model, in favour of a strong one. I do not know of the demangler being taught this. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27865] Unsupported name-unmangling for C++20 modules?
https://sourceware.org/bugzilla/show_bug.cgi?id=27865 --- Comment #3 from Andrew V. Jones --- Hi Nick, So, I did actually ask this on the GCC mailing list: https://gcc.gnu.org/pipermail/gcc/2021-May/236057.html but I'm yet to receive a response. I'd actually be totally fine to give a go at implementing this inside of libiberty, but I don't actually know how the module function should be demangled, to avoid ambiguity with the namespace case. Are you aware of any other places where two (different) mangled names get unmangled to the same thing? Cheers, Andrew -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27865] Unsupported name-unmangling for C++20 modules?
https://sourceware.org/bugzilla/show_bug.cgi?id=27865 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #2 from Nick Clifton --- Hi Andrew, The binutils uses the libiberty library to handle demangling. This library is actually owned and maintained by the GCC project. We just take clones of the latest code from time to time and import it into the binutils branches. As far as I can see the gcc libiberty sources have not yet been update to handle demangling module names, but I could be wrong. If/when those sources are updated then please ping the binutils mailing list (or this PR) so that we know that it is time to take another snapshot. It may also be worthwhile filing a gcc PR to prod the libiberty maintainers. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/27869] gold lto link corrupt with segmentation fault [signal 11]
https://sourceware.org/bugzilla/show_bug.cgi?id=27869
--- Comment #2 from web_hero ---
(In reply to Cary Coutant from comment #1)
> Based on that stack trace, you appear to be linking an output file that has
> more than 64K sections in it. Obviously, gold should not be crashing when
> that happens, but what on earth are you linking that has so many output
> sections? That just shouldn't happen in any practical application. Solving
> that may work around this bug.
>
> Please add "-v -Wl,--debug=plugin" options, and send me the verbose gcc
> output and a tar file of the resulting debug directory.
I use -ffunction-sections
maybe this cause too many sections？
this opt option was used to reorder function in link stage
It seems relative to my custom ld script:
-Wl,-znorelro -Wl,-T,${CMAKE_SOURCE_DIR}/rpm/ld.lds
When I remove : -Wl,-T,${CMAKE_SOURCE_DIR}/rpm/ld.lds
It success.
The link script’s content is:
SECTIONS
{
memory_context_static_id :
{
KEEP(*(SORT(memory_context_static_id*)));
}
co_buffer :
{
KEEP(*(*CO_BUFFER_BEGIN*))
KEEP(*(*COBUFFER*))
KEEP(*(*CO_BUFFER_END*))
}
co_hook :
{
KEEP(*(*CO_HOOK_BEGIN*))
KEEP(*(*COHOOK*))
KEEP(*(*CO_HOOK_END*))
}
}
is it caused by incorrect usage of ld script for gold ?
If so, how can I use this script correctly for gold.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gas/25599] gas generates invalid PCREL60B relocation offset with brl.call
https://sourceware.org/bugzilla/show_bug.cgi?id=25599
--- Comment #5 from dave.anglin at bell dot net ---
Hi John,
Please send change to binutils list with install request. CC Jim Wilson and
myself. Jim is the
expert on ia64 assembly code.
There are some GNU style issues with the change as written. The declaration of
"where"
should be at the start of the block. There should be no space after "(" or
before ")". "where++"
should be on following line. Check white space.
The Debian ia64 Linux port is still active, so I don't think ia64 should be
obsoleted at this time.
After the binutils change is accepted, please submit gcc changes to the gcc
patches list. Please
test change on master if possible.
On 2021-05-17 6:07 a.m., jvb at cyberscience dot com wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=25599
>
> John Buddery changed:
>
>What|Removed |Added
>
> CC||jvb at cyberscience dot com
>
> --- Comment #4 from John Buddery ---
> Here's the solution I used to fix the PCREL60B offset for HP:
>
> --- binutils-2.36/gas/config/tc-ia64.c 2021-01-09 10:47:33.0 +
> +++ binutils-2.36-snake/gas/config/tc-ia64.c2021-05-17 10:21:40.651307362
> +0100
> @@ -6892,7 +6892,13 @@
>for (j = 0; j < md.slot[curr].num_fixups; ++j)
> {
> ifix = md.slot[curr].fixup + j;
> - fix = fix_new_exp (frag_now, frag_now_fix () - 16 + i, 8,
> +
> + unsigned long where = frag_now_fix () - 16 + i;
> +#ifdef TE_HPUX
> + if ( ifix->code == BFD_RELOC_IA64_PCREL60B ) where++;
> +#endif
> +
> + fix = fix_new_exp (frag_now, where, 8,
> >expr, ifix->is_pcrel, ifix->code);
> fix->tc_fix_data.opnd = ifix->opnd;
> fix->fx_file = md.slot[curr].src_file;
>
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug libctf/27360] libctf.so.0: undefined symbol: bsearch_r
https://sourceware.org/bugzilla/show_bug.cgi?id=27360 --- Comment #18 from Nick Alcock --- Yeah, that's only true if the distributor chooses to install the iibiberty.a from GCC in /usr/lib (or, I suppose, the one from a sufficiently recnet binutils). I do still want to figure out how to fix this properly. Sorry it's taking me so long to get to it... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25599] gas generates invalid PCREL60B relocation offset with brl.call
https://sourceware.org/bugzilla/show_bug.cgi?id=25599
John Buddery changed:
What|Removed |Added
CC||jvb at cyberscience dot com
--- Comment #4 from John Buddery ---
Here's the solution I used to fix the PCREL60B offset for HP:
--- binutils-2.36/gas/config/tc-ia64.c 2021-01-09 10:47:33.0 +
+++ binutils-2.36-snake/gas/config/tc-ia64.c2021-05-17 10:21:40.651307362
+0100
@@ -6892,7 +6892,13 @@
for (j = 0; j < md.slot[curr].num_fixups; ++j)
{
ifix = md.slot[curr].fixup + j;
- fix = fix_new_exp (frag_now, frag_now_fix () - 16 + i, 8,
+
+ unsigned long where = frag_now_fix () - 16 + i;
+#ifdef TE_HPUX
+ if ( ifix->code == BFD_RELOC_IA64_PCREL60B ) where++;
+#endif
+
+ fix = fix_new_exp (frag_now, where, 8,
>expr, ifix->is_pcrel, ifix->code);
fix->tc_fix_data.opnd = ifix->opnd;
fix->fx_file = md.slot[curr].src_file;
I've made the change HP specific, as I'm not sure the binutils linker treats
the offset the same way, and I've no way to test.
I've tested this and it works for brl instructions in all the cases I've seen
(including a full bootstrap of gcc and a separate large project build).
I know this platform is obsoleted in 2.36, but as it's the only way to get a
working modern gcc version, it would be really helpful if this change or
something similar could be accepted.
---
John
--
You are receiving this mail because:
You are on the CC list for the bug.
