[Bug gas/28262] Add warning when generating code in data section
https://sourceware.org/bugzilla/show_bug.cgi?id=28262 --- Comment #3 from Andreas Schwab --- Is 0x13 code or data? -- 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 Assignee|unassigned at sourceware dot org |nickc at redhat dot com CC||nickc at redhat dot com Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-09-06 Ever confirmed|0 |1 --- Comment #1 from Nick Clifton --- Investigating -- 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 --- Comment #2 from Nick Clifton --- Created attachment 13655 --> https://sourceware.org/bugzilla/attachment.cgi?id=13655&action=edit Proposed patch Possible patch to fix the problem -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28304] objdump crashes in bfd_get_symcount
https://sourceware.org/bugzilla/show_bug.cgi?id=28304 Nick Clifton changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-09-06 CC||nickc at redhat dot com Assignee|unassigned at sourceware dot org |nickc at redhat dot com --- Comment #1 from Nick Clifton --- investigating -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28304] objdump crashes in bfd_get_symcount
https://sourceware.org/bugzilla/show_bug.cgi?id=28304 --- Comment #2 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=804439b4d7a83d4db8adcb816d8ee8e04a06b33c commit 804439b4d7a83d4db8adcb816d8ee8e04a06b33c Author: Nick Clifton Date: Mon Sep 6 12:24:49 2021 +0100 Fix an illegal memory access triggered by disassembling corrupt s390x binaries. PR 28304 * elfxx-score7.c (score_elf_gprel15_reloc): If there is no output bfd treat the reloc as undefined. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28304] objdump crashes in bfd_get_symcount
https://sourceware.org/bugzilla/show_bug.cgi?id=28304 Nick Clifton changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Nick Clifton --- Hi Shaohua Li, I have checked in a small patch to fix this bug. 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 #4 from Nick Clifton --- (In reply to Dietmar May from comment #2) > This assembled, linked, ran Ran in what environment ? I agree that the processor itself will happily attempt to execute anything that it is pointed at, regardless of whether it is data or assembled code. But the point is that any reasonable operating system should never ask the processor to execute data. So how did the assembled-into-a-data-section code get executed ? > However, perhaps because of the layout in the ld file, 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). > Me, I'm still confused as to why any section that contains only assembler > code would default to be data. Seems like the default for a section should > depend on what that section contains ... Which would require that the assembler looks ahead through the input source in an attempt to determine if instructions or data are going to be placed into the just-declared section. (There is also a general principle that if you are creating hand written assembler code then you do need to know what you are doing. Not that the assembler can't be helpful per se, but too much hand holding is going make the assembler a lot slower...) -- 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 #4 from Nick Clifton --- (In reply to Joel Rosdahl from comment #3) Hi Joel, > Here is how to reproduce the issue: > > % cd /tmp > % echo 'int x;' >test.c > % /usr/bin/gcc -g -fdebug-prefix-map=/tmp=/example -c test.c > % objdump -W test.o 2>/dev/null | grep -E '/tmp|/example' > <16> DW_AT_comp_dir: (indirect line string, offset: 0x0): > /example > 0 (indirect line string, offset: 0x10): /tmp > 1 (indirect line string, offset: 0x15): /example > 0x 2f657861 6d706c65 00746573 742e6300 /example.test.c. > 0x0010 2f746d70 002f6578 616d706c 65007465 /tmp./example.te OK, well I cannot reproduce that behaviour, but I agree that it is wrong. Do you have a suggested patch to fix the problem ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28306] nm-new: null pointer dereference in bfd_getl16
https://sourceware.org/bugzilla/show_bug.cgi?id=28306 Alan Modra changed: What|Removed |Added Assignee|unassigned at sourceware dot org |amodra at gmail dot com Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2021-09-06 -- 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 Palmer Dabbelt changed: What|Removed |Added CC||palmer at gcc dot gnu.org --- Comment #3 from Palmer Dabbelt --- I see a bunch of if (reloc_entry->address > bfd_get_section_limit (abfd, input_section)) return bfd_reloc_outofrange; in the MIPS port, which is subtly different than this. I don't really care which error value to pick, but I guess ">" is a touch better than ">=". Like Nick said, the proposed solution is sort of just a hack. Given that it seems like a common idiom I'm fine with it, but it does seem preferable to hoist this into some generic code (I'd be tempted to try and check the bounds there, but IDK if that's sane). -- 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 --- Comment #4 from Alan Modra --- The canonical check is octets = reloc_entry->address * bfd_octets_per_byte (abfd, input_section); if (!bfd_reloc_offset_in_range (reloc_entry->howto, abfd, input_section, octets)) return bfd_reloc_outofrange; For riscv you can leave out bfd_octets_per_byte, or use an OCTETS_PER_BYTE macro defined to 1 as I do for ppc. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27442] FAIL: Local ifunc-using executable does not contain R_*_IRELATIVE relocation
https://sourceware.org/bugzilla/show_bug.cgi?id=27442 Sam James changed: What|Removed |Added CC||sam at gentoo dot org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28307] nm-new: SEGV caused by a WRITE memory access
https://sourceware.org/bugzilla/show_bug.cgi?id=28307 --- Comment #1 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=b54509b84488023954f6974229b24fe6c993742b commit b54509b84488023954f6974229b24fe6c993742b Author: Alan Modra Date: Mon Sep 6 22:23:15 2021 +0930 PR28307, segfault in ppc64_elf_toc64_reloc Adds missing bfd_reloc_offset_in_range checks to various relocation special_functions. PR 28307 * elf32-ppc.c (ppc_elf_addr16_ha_reloc): Range check reloc offset. * elf64-ppc.c (ppc64_elf_ha_reloc, ppc64_elf_brtaken_reloc): Likewise. (ppc64_elf_toc64_reloc, ppc64_elf_prefix_reloc): Likewise. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28307] segfault in ppc64_elf_toc64_reloc
https://sourceware.org/bugzilla/show_bug.cgi?id=28307 Alan Modra changed: What|Removed |Added Resolution|--- |FIXED Summary|nm-new: SEGV caused by a|segfault in |WRITE memory access |ppc64_elf_toc64_reloc Status|ASSIGNED|RESOLVED --- Comment #2 from Alan Modra --- Fixed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/28311] New: `weak_undef_test` failing with gcc versions newer than 5.4.0 (Ubuntu 16.04)
https://sourceware.org/bugzilla/show_bug.cgi?id=28311 Bug ID: 28311 Summary: `weak_undef_test` failing with gcc versions newer than 5.4.0 (Ubuntu 16.04) Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: saldivarcher at gmail dot com CC: ian at airs dot com Target Milestone: --- As stated in bug 22755, tests are failing in newer gcc versions, I haven't been able to find the exact version where the change in gcc happened. GCC 5.3.0: # weak_undef_test.s movl$no_such_symbol_, %eax # weak_undef_test.o f: b8 00 00 00 00 mov$0x0,%eax 10: R_X86_64_32 no_such_symbol_ # weak_undef_test 4006e5: b8 00 00 00 00 mov$0x0,%eax GCC 9.3.0: # weak_undef_test.s movqno_such_symbol_@GOTPCREL(%rip), %rax # weak_undef_test.o f: 48 8b 05 00 00 00 00mov0x0(%rip),%rax 12: R_X86_64_REX_GOTPCRELX no_such_symbol_-0x4 # weak_undef_test 7e8: 48 8b 05 f1 17 00 00mov0x17f1(%rip),%rax # 1fe0 So I'm assuming that the way weak symbols resolve have changed, and the test should probably be changed to reflect that. -- You are receiving this mail because: You are on the CC list for the bug.
