[Bug binutils/28303] objdump crashes in riscv_elf_add_sub_reloc
https://sourceware.org/bugzilla/show_bug.cgi?id=28303 --- Comment #5 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=3f1a2892e1fea343880b276474cb44db3abcaa9a commit 3f1a2892e1fea343880b276474cb44db3abcaa9a Author: Nick Clifton Date: Tue Sep 7 09:44:17 2021 +0100 Fix illegal memory access triggered by an attempt to disassemble a corrupt RISC-V binary. PR 28303 * elfxx-riscv.c (riscv_elf_add_sub_reloc): Add check for out of range relocs. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28303] objdump crashes in riscv_elf_add_sub_reloc
https://sourceware.org/bugzilla/show_bug.cgi?id=28303 Nick Clifton changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Nick Clifton --- Thanks Alan. I have gone ahead and applied a patch based upon your suggestion. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28305] ojbjdump: heap-buffer-overflow in xtensa_insnbuf_from_chars
https://sourceware.org/bugzilla/show_bug.cgi?id=28305 --- Comment #1 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=9dc2f26777b07f9e5aa3220f7a680987ef79e75e commit 9dc2f26777b07f9e5aa3220f7a680987ef79e75e Author: Nick Clifton Date: Tue Sep 7 11:47:08 2021 +0100 Fix an illegal memory access triggered by an atempt to disassemble a corrupt xtensa binary. PR 28305 * elf32-xtensa.c (elf_xtensa_do_reloc): Add check for put of range reloc. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28305] ojbjdump: heap-buffer-overflow in xtensa_insnbuf_from_chars
https://sourceware.org/bugzilla/show_bug.cgi?id=28305 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC||nickc at redhat dot com --- Comment #2 from Nick Clifton --- Hi Shaohua Li, Thanks for reporting this bug. I have checked in a small patch to fix the problem. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/28262] Add warning when generating code in data section
https://sourceware.org/bugzilla/show_bug.cgi?id=28262 --- Comment #5 from Dietmar May --- > Ran in what environment ? Bare metal aarch64 boot loader - the very first steps in bring up an existing custom operating system on a new hardware platform. > So how did the assembled-into-a-data-section code get executed ? It's a multi-core processor, each core has a distinct _start: memory address. Therefore, each core has to have its own .text section, except they can't be called .text, because there are multiple distinct sections. The assembler code is just a few hundred lines - disables interrupts, watchdogs, sets up MMU. Then it branches to C/C++ code (ie. _main:), with the occasional GCC inline assembler block. > Do you mean the linker script ? Maybe this is the problem. Maybe the > script is putting data input sections into a executable output section > (or segment). Well, yes, that's what the linker script does. But, hmm, is that the problem? Reason that an assembler exists: to convert symbolic mnemonics into hexadecimal (or binary) machine op codes that a CPU can execute. Reasons sections exist: to break up code into individual, relocatable blocks of machine op codes. Default meaning of sections: data! Huh? I've been told that's to prevent people who are writing self-relocating code from accidentially opening security holes. But why turn code quietly into data, by default? If someone wants to write self-relocating code, they can specify the section type as data. If it's really that dangerous to have code default to being code, then remove the default! Though that would undoubtedly break existing codebases. So if that's not desirable, then at least issue a warning. > Which would require that the assembler looks ahead through the input source Or that the assembler sets a flag when is sees and assembles code within a defaulted section, and when it reaches the end of the section, it emits a warning if the flag is set. > a general principle that ... you do need to know what you are doing I've been writing C++ code since shortly after Stroustrup released his first edition of The C++ Programming Language; and I've done x86 and embedded assembler, as well as bare metal machine language. I'm not a novice developer. However, I am far more comfortable with g++ than with gas; this is my first dive into using gas; and I'll be the first to admit I have a lot to learn. I was helping to port a bootloader from a commercial compiler/assembler suite to g++/gas, and the syntax is more than a bit different. So I searched, and found lots of examples of .text, .bss, .data sections. None of them were qualified with optional flags - because they're well known section names. I found no examples of more complex scenarios, like .text1, .text2, etc. And in adapting .text examples to .text1, .text2, gas happily assembled and ld happily linked the code, without any warnings or errors. And the processor happily ran the code, and gdb happily debugged the code. And so I was happy :-) ... until binutils 2.36.1 broke debugging. Perhaps an example of something more than "Hello World" would be really useful. Most of all, I think that .section should not have any default, except perhaps for well known names like .text; and then the programmer is forced to make a decision about what the section should be. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/28314] New: [AArch64] Insufficient veneer stub alignment (gold)
https://sourceware.org/bugzilla/show_bug.cgi?id=28314 Bug ID: 28314 Summary: [AArch64] Insufficient veneer stub alignment (gold) Product: binutils Version: 2.35.1 Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: andre.paquette at nokia dot com CC: ian at airs dot com, jeremip11 at gmail dot com, nickc at redhat dot com, pexu at sourceware dot mail.kapsi.fi, unassigned at sourceware dot org, wilson at gcc dot gnu.org Target Milestone: --- +++ This bug was initially created as a clone of Bug #22903 +++ Hi there. It looks like bug 22903 was only fixed for ld and is still an issue in gold. As an experiment I increased STUB_ADDR_ALIGN to 8 for Reloc_stub and that does resolve the issue. I'm not sure if increasing the alignment is appropriate to all reloc stub types, so this was just a proof of concept. diff --git a/gold/aarch64.cc b/gold/aarch64.cc index 07abe44931..7626fcad4a 100644 --- a/gold/aarch64.cc +++ b/gold/aarch64.cc @@ -1317,7 +1317,7 @@ class Reloc_stub : public Stub_base }; // End of Reloc_stub template -const int Reloc_stub::STUB_ADDR_ALIGN = 4; +const int Reloc_stub::STUB_ADDR_ALIGN = 8; // Write data to output file. Original description from bug #22903 follows. Hi. It is not currently possible to specify an alignment requirement that will be used for generated veneer stubs (i.e. far calls for -fpic, -fpie etc. builds). Currently, the alignment for the stubs is 4 bytes. While this works just fine for the majority of the systems, it works only because many requisite deeds has been done beforehand (and a hint of luck, too). The problematic veneer template (aarch64_long_branch_stub at bfd/elfnn-aarch64.c) uses LDR to load the far address. The address itself is stored after the veneer code block, which does the address loading (via LDR/ADD) and branching. The template looks like this: ldr ip0, 1f # <-- ip0, i.e. X16, i.e. 64-bit register adr ip1, #0 add ip0, ip0, ip1 br ip0 1: .xword While the address is 8-byte aligned within the stub itself, it will be misaligned unless the veneer lands on a 8-byte (or more) aligned address. ARMv8-A ARM clearly states, that unless an address is accessed to the size of the data element being accessed (i.e. N-bit accesses must be N-bit aligned) either an Alignment fault is generated or an unaligned access is performed. It is possible to disable the alignment check, and thus perform an unaligned access, via system register SCTLR_ELx.A (e.g. the case for Linux). However, there's a small catch 22 that is well buried into the small details within the ARM. If the stage 1 address translation is disabled (e.g. MMU disabled), Device-nGnRnE memory type is assigned to all data accesses (or the address simply happens to be some type of Device memory, nothing unusual with SoCs). Unlike Normal memory type, all accesses to any type of Device memory *must* be aligned, period. So, if the code has to deal with a large memory area and is not able to use MMU (say, not available or being set up), and thus no address translation is enabled, or for whatever reason uses Device memory type, LD's current approach will generate code, that is highly prone to intermittent failures that could be difficult to track down (without proper JTAG tools) as no matter how well the user does his task, the generated code is the source of the failure. Also, it should be understood that it would be an overkill and highly complex task trying to recover from this sort of exception (must interpret the bytecode, then perform aligned access(es), maybe patch the bytecode etc.) while the proper thing to do is to simply not perform any unaligned accesses when such accesses are not possible. Obviously, one can always just generate the long branches by hand, maybe use static linking where possible, so this is not a roadblocker by no means. As the subject is rather undocumented and there's apparently a patch readily available, this should be fixed. Perhaps there is no need to change the default alignment (without further studies), but it should be possible to change the alignment nevertheless. I hope I provided enough background information for this rare, but indeed curious case! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/28266] CWD present in object file even after use of -fdebug-prefix-map=$PWD=foo
https://sourceware.org/bugzilla/show_bug.cgi?id=28266
--- Comment #5 from Joel Rosdahl ---
Created attachment 13656
--> https://sourceware.org/bugzilla/attachment.cgi?id=13656&action=edit
gas: Apply debug prefix map to DWARF-5 PWD entry in directory table
(In reply to Nick Clifton from comment #4)
> OK, well I cannot reproduce that behaviour
Oh, that's peculiar. Here's the reproduction recipe in self-contained script
form:
#!/bin/sh
tmpdir=$(mktemp -d)
trap "rm -rf ${tmpdir}" EXIT
cd $tmpdir
echo 'int x;' >test.c
/usr/bin/gcc -g -fdebug-prefix-map="${tmpdir}=/example" -c test.c
if grep -q "${tmpdir}" test.o; then
echo "FAIL: PWD found in object file"
else
echo "OK"
fi
With binutils-2.35.1-41.fc34.x86_64.rpm:
% ./repro
OK
With binutils-2.35.2-5.fc34.x86_64.rpm:
% ./repro
FAIL: PWD found in object file
> Do you have a suggested patch to fix the problem ?
I didn't, but after having spent some time in the GAS code I now have. See
attachment.
One thing that I'm not 100% sure of is if it's OK to rely on
$COLLECT_GCC_OPTIONS in GAS. I haven't studied how that variable is used by
other parts of the toolchain; I only noted that it's available and contains the
information we need.
--
You are receiving this mail because:
You are on the CC list for the bug.
