[Bug binutils/18741] Corrupted .ARM.attributes section with -meabi=gnu option
https://sourceware.org/bugzilla/show_bug.cgi?id=18741 --- Comment #6 from Nick Clifton --- Created attachment 8519 --> https://sourceware.org/bugzilla/attachment.cgi?id=8519&action=edit example object 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 binutils/18741] Corrupted .ARM.attributes section with -meabi=gnu option
https://sourceware.org/bugzilla/show_bug.cgi?id=18741 --- Comment #7 from Nick Clifton --- Hi Markus, > Compile an empty source-file (I.e. empty.c) with: >arm-eabi-gcc -c -mabi=apcs-gnu empty.c >arm-eabi-readelf -a empty.o > will show the .ARM.attributes section (type ARM_ATTRIBUTES) with a > size of 16 byte. Well I tried this using the FSF GCC and binutils mainline sources and the problem did not occur - ie the object file contains the correct attributes and readelf does not complain. I have uploaded a copy of the object file for you to examine if you wish. My guess is that this is a bug which has already been fixed, some time after 2.25 was released. Since it is a minor problem I am not going to search for the patch and backport it to 2.25, unless you can convince me otherwise. 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 gas/18826] New: REL vs RELA relocations by default in the ARM backend
https://sourceware.org/bugzilla/show_bug.cgi?id=18826 Bug ID: 18826 Summary: REL vs RELA relocations by default in the ARM backend Product: binutils Version: 2.26 (HEAD) Status: NEW Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: ramana at sourceware dot org Target Milestone: --- Given this testcase: .arch armv7-a .syntax unified .text movwr10, #:lower16:nshel_+268000 movtr10, #:upper16:nshel_+268000 .data .global nshel_ .space 2 nshel_: .space 40 $INSTALL/bin/arm-none-linux-gnueabihf-gcc -c /tmp/movw.s /tmp/movw.s: Assembler messages: /tmp/movw.s:6: Error: offset out of range /tmp/movw.s:7: Error: offset out of range Is there an easy way to choose RELA relocations on a particular relocation type or at a particular architecture level ? I couldn't find an easy way to do this as the choice in the arm backend happens to be based on "use_rel". While we can work around this in the compiler by not allowing offsets > the offset allowed, I consider it a bug in the assembler and linker that we are unable to represent such constant offsets in symbol expressions in the assembler purely because of a representation issue. I note that in the ARM backend a number of sub-"targets" like vxworks and QNX are already using RELA relocations by default which suggests to me that the logic is already in there and reasonably safe (additionally I do see a check for REL vs RELA in large parts of the backend). Alternatively we could consider switching the backend to using RELA relocation types but that's a task that may have a pretty big impact in terms of correctness and I'm not sure how gold will deal with this sort of an issue currently. -- 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/18741] Corrupted .ARM.attributes section with -meabi=gnu option
https://sourceware.org/bugzilla/show_bug.cgi?id=18741 --- Comment #8 from markus.eisenmann at gmx dot at --- Hi Nick! The readelf-output (Version 2.25) of your sample is (showing ARM-Attributes): Attribute Section: aeabi File Attributes Tag_ARM_ISA_use: Yes Tag_THUMB_ISA_use: Thumb-1 It contains sub-fields; I.e., it seems, that with binutils mainline these two default-attributes are emitted (instead of nothing as before for OABI). > My guess is that this is a bug which has already been fixed, some time after > 2.25 was released. Since it is a minor problem I am not going to search for > the patch and backport it to 2.25, unless you can convince me otherwise. No, thanks - it is fixed for future releases. And as I have described in comment #5, I have a (private) work-around or will discard the .ARM.attributes-section at link-time (with a linker-script) to make our post-processing ELF-utilities happy! BR, Markus -- 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/18826] REL vs RELA relocations by default in the ARM backend
https://sourceware.org/bugzilla/show_bug.cgi?id=18826 --- Comment #1 from joseph at codesourcery dot com --- In principle BFD supports mixed REL / RELA relocations in a single input object file. I think the tic6x back end supports it, for example (or at least was meant to, but it's a while since I did anything with that back end), and some MIPS cases may support it. I don't think the ARM back end has such support (although I think it's strictly required by the EABI - that is, valid EABI-conforming objects may mix REL and RELA). I don't know if mixing REL and RELA on *output* is supported at all by BFD. -- 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/18829] New: Add the ability to sort PLT entries
https://sourceware.org/bugzilla/show_bug.cgi?id=18829 Bug ID: 18829 Summary: Add the ability to sort PLT entries Product: binutils Version: 2.26 (HEAD) Status: NEW Severity: enhancement Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: gregory.d.bentley at intel dot com Target Milestone: --- Created attachment 8524 --> https://sourceware.org/bugzilla/attachment.cgi?id=8524&action=edit binutils patch to add -z sortplt The jump instructions in the Procedure Linkage Table which effect the jump into shared library functions are laid out in more or less random order. While one can use a linker script to get more cache friendly layout of functions within an executable, there is currently no way to explicitly specify the order of the PLT entries. This means you can get into the situation where you have only 1 jump instruction (6 bytes) being "hot" on a 64 byte cache line. The attached patch allows a user to specify a file which lists the names of hot shared library functions. The PLT entries for those functions will be placed into the table first, with any unspecified functions following. The syntax is -z sortplt= (As a side note, -z bndplt also gives more cache friendly code as it splits the cold (first call) code from the hot (every call) code.) -- 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/18829] Add the ability to sort PLT entries
https://sourceware.org/bugzilla/show_bug.cgi?id=18829 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #1 from H.J. Lu --- Have you tried -fno-plt option in GCC 6? It removes PLT and calls external functions via GOT directly. -- 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/18829] Add the ability to sort PLT entries
https://sourceware.org/bugzilla/show_bug.cgi?id=18829 --- Comment #2 from Greg Bentley --- (In reply to H.J. Lu from comment #1) > Have you tried -fno-plt option in GCC 6? It removes PLT > and calls external functions via GOT directly. No, I hadn't heard of that option. Thanks for the pointer. It looks like it will avoid the poor cache use I'm concerned with. Unfortunately it will be quite a while before my project will moves to gcc 6. -- 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/18826] REL vs RELA relocations by default in the ARM backend
https://sourceware.org/bugzilla/show_bug.cgi?id=18826 Alan Modra changed: What|Removed |Added Status|NEW |RESOLVED CC||amodra at gmail dot com Resolution|--- |INVALID --- Comment #2 from Alan Modra --- I'm closing the bug as invalid since it is clear to me that gas and ld are not at fault here. Here's why: The bug/limitation is really in the ABI. REL relocs are not the best choice for targets like ARM and PowerPC that use multiple instructions to build an address constant. You either store the same addend in each insn field (the choice made by ARM), which limits the addend range, or you store parts of the addend over multiple insns. The latter choice means the linker (and loader) need to piece together the addend somehow, and in practical terms that limits your code generation. The pieces need to be kept together, at least in the same section and not have any other intervening insn requiring relocs. Which is nasty, and IMO worse than the ARM choice. Mixed rel/rela comes with its own set of problems. For instance, the rel and rela relocs must be separated into two sections, because a relocation section is a regular array of entries and the two types differ in size. If you wanted both rel and rela output (dynamic) relocs, then you'd need a whole lot of linker changes and you'd possibly need ld.so changes. (On the face of it, ld.so looks like it supports both types, but I'm not aware of any target than makes use of both rel and rela dynamic relocs, so that feature is untested.) Besides that, having two dynamic reloc sections imposes an ordering on reloc processing, which may clash with other requirements such as processing ifunc relocs last. Just switch to RELA. -- 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
