[Bug ld/17505] arm: bad static label resolution from different modes
https://sourceware.org/bugzilla/show_bug.cgi?id=17505 Richard Earnshaw changed: What|Removed |Added CC||rearnsha at gcc dot gnu.org --- Comment #5 from Richard Earnshaw --- (In reply to Christian Bruel from comment #1) > Encoding a BFD_RELOC_ARM_PCREL_BLX instead of a BFD_RELOC_ARM_PCREL_CALL for > static calls between arm to thumb fixed the problem. That sounds wrong. Which architecture revision are you targeting? -- 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/17505] arm: bad static label resolution from different modes
https://sourceware.org/bugzilla/show_bug.cgi?id=17505 --- Comment #7 from Richard Earnshaw --- > What is surprising is that the linker correctly patches the BL/BLX instru ctions, itś just the address that is wrong. I´m wondering if this can be fixed in the linker machinery to handle interwork or have the assem bly emit a R_ARM_THM_CALL reloc I think you're being confused by the disassembler. The two symbols are at the same address (there's no code in between the two); so the disassembler just picks one of them to print out. I still don't see anything wrong with what's being generated by the assembler/linker. -- 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/29519] .unreq does not handle line separator characters as such
https://sourceware.org/bugzilla/show_bug.cgi?id=29519 Richard Earnshaw changed: What|Removed |Added CC||rearnsha at gcc dot gnu.org --- Comment #2 from Richard Earnshaw --- I have a fix for the .unreq. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29519] .unreq does not handle line separator characters as such
https://sourceware.org/bugzilla/show_bug.cgi?id=29519 --- Comment #3 from Richard Earnshaw --- The slightly strange thing is that the front-end parser passes the entire buffer to a directive statement, unlike md_assemble which is just passed a single statement. It's not at all clear why that is. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29519] .unreq does not handle line separator characters as such
https://sourceware.org/bugzilla/show_bug.cgi?id=29519 Richard Earnshaw changed: What|Removed |Added Status|ASSIGNED|NEW --- Comment #6 from Richard Earnshaw --- I think there's a simpler fix than that, we can just use find_end_of_line(). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29519] .unreq does not handle line separator characters as such
https://sourceware.org/bugzilla/show_bug.cgi?id=29519 --- Comment #7 from Richard Earnshaw --- Fixed for arm with https://sourceware.org/pipermail/binutils/2022-August/122587.html, but need something similar for aarch64. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/22589] aarch64: adrp relocation gets filled with non-zero address for undefined weak symbol
https://sourceware.org/bugzilla/show_bug.cgi?id=22589 --- Comment #10 from Richard Earnshaw --- (In reply to Szabolcs Nagy from comment #9) > i ran into this again and i think the linker could relax 'adrp xN, weaksym' > into 'mov xN, 0' if weaksym is undefined. Static linker or dynamic? The dynamic linker can't change any code segment during loading, since that would break the code-sharing model used by SVr4-like systems. I don't see how the static linker can know that a dynamically loaded library won't provide a definition at run-time, so that doesn't make a lot of sense to me either. > > link error is not helpful since such code (accessing weak symbols) may be > behind checks and unreachable if the symbol is undefined. > > normally weak syms are accessed via GOT which can be 0 for undef, but in PIC > this depends on a dynamic relocation even for hidden visibility syms. this > does not work in early start code (e.g. *crt1.o) accessing weak, linker > generated symbols (such as __ehdr_start) where the code must not generate > dynamic relocations (since it may be executed before ld.so or static pie > self relocation). if such symbol is potentially undefined then we have a > problem: adrp does not work, GOT does not work, movz does not work. so i > dont see a way to implement > > if (&weaksym != 0) > use(&weaksym); > > logic in the ld.so or static pie start code. i ran into this with the > morello port where there are linker created symbols (__rela_dyn_start) that > are only defined under certain conditions (static exe with no > dynamic-linker) and must be checked and accessed in gcrt1.o that is used in > both pde and pie. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29718] readelf prints out ": 10" instead of "IFUNC"
https://sourceware.org/bugzilla/show_bug.cgi?id=29718 Richard Earnshaw changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-11-25 Resolution|FIXED |--- CC||rearnsha at gcc dot gnu.org Status|RESOLVED|REOPENED --- Comment #6 from Richard Earnshaw --- Sorry, I think this is wrong. You cannot assume anything about a field defined to be in the OSABI space if the OSABI field is not set. It doesn't matter that the tools have been lazy in not enforcing this correctly. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/22589] aarch64: adrp relocation gets filled with non-zero address for undefined weak symbol
https://sourceware.org/bugzilla/show_bug.cgi?id=22589 Richard Earnshaw changed: What|Removed |Added CC||rearnsha at gcc dot gnu.org --- Comment #3 from Richard Earnshaw --- It's simply not safe to use adrp to reference a weak symbol. If you're hand-writing assembly you have to be aware of this. adrp is a position-independent address-forming instruction; as such it cannot ever resolve to zero and still be position independent; that would require dynamic relocation which would in turn imply having a writable text section. Furthermore, the offset range of adrp is such that it probably could not generate zero. It might be nice if the assembler/linker could detect this case and emit an out-of-bounds error - it's essentially a relocation overflow. I'm not sure if that's a generic issue or a back-end one. Anyway, it's still invalid to use adrp to form a reference to a weak symbol. -- 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/22589] aarch64: adrp relocation gets filled with non-zero address for undefined weak symbol
https://sourceware.org/bugzilla/show_bug.cgi?id=22589 Richard Earnshaw changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |INVALID --- Comment #5 from Richard Earnshaw --- (In reply to Julius Werner from comment #4) > Hi Richard, > > Sorry, I can't quite follow your argumentation. Are you trying to say that > it's not legal to use the ADRP instruction in position-dependent code? No, I'm saying you can't use ADRP for a *weak* symbol reference in position independent code. > I'm > not really sure what you're basing that assumption on... I can't find > anything to that effect in any of the official ARM documentation and specs. What documentation? ARM docs don't say you can use a division instruction for doing general addition, but clearly you can't... > The instruction may be useful for position-independent code and often used > by compilers to this effect, yes, but that doesn't mean that this is the > only valid use for it and that it isn't allowed for anything else (unless > ARM explicitly specified it like that, which to my knowledge they didn't). > If I'm hand-writing assembly and I want to use the instruction in a way that > is compliant with the spec, I think binutils should accept and link that > correctly. It's all a consequence of the requirements on the binary and the constraints that imposes. Building code that is PIC takes some care and consideration of the operating constraints. Code, even PIC, needs to be read-only (no dynamic relocations) and that means that after static linking there must be no outstanding relocations on the binary. With weak symbols we don't know until run-time whether or not the symbol will be defined. The two constraints are incompatible with each other if we allow ADRP to reference a weak symbol. It's not just weak symbols have this property; symbol pre-emption can have a similar impact. The rules for building an ELF image that is workable can and do restrict which instructions can be used in which contexts. You as the programmer have to understand this, just as a compiler has to. > > FWIW, this instruction is useful for any load from a compile-time-known > address in position-dependent code where the address is guaranteed to be > less than 4GB away from the program counter (but may be further away than > the 32KB addressable directly by an LDR (immediate) instruction). But it's not compile-time known. That's the point. > This is a > pretty common use case for firmware and embedded applications which often > use a 1:1 virtual to physical mapping and only need to operate on the DRAM > and MMIO addresses within 0 and 4GB. It's more compact than the LDR , > = mnemonic which translates into 12 bytes of code (compared to 8 > bytes for ADRP and a normal LDR). > > I understand that there are cases where the instruction could not output 0 > (i.e. if the PC is above 4GB), and I agree that linking should fail with a > relocation overflow in that case. But for cases where it does fit, I think > it's clearly more correct to output an instruction that results in 0 rather > than whatever it's doing right now (which is clearly just wrong, one way or > another). See also my earlier post about how it works perfectly fine for a > defined symbol with value 0. It makes absolutely no sense that this should > give a different result than an undefined weak symbol, they both resolve to > exactly the same address. That's not the model implemented in GNU binutils. Nor is it the model wanted for normal PIC 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/24596] linker segmentation faults
https://sourceware.org/bugzilla/show_bug.cgi?id=24596 Richard Earnshaw changed: What|Removed |Added CC||rearnsha at gcc dot gnu.org --- Comment #12 from Richard Earnshaw --- (In reply to Alan Modra from comment #11) > The only segfaults I see now are on arm-symbianelf and s12z-elf. I'm going > to leave those to target maintainers.. Is symbianelf still relevant? Symbian ceased to exist over 10 years ago now. -- 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/25406] [ARM] pcrel relocations referencing STB_GLOBAL symbols are resolved at assembly time
https://sourceware.org/bugzilla/show_bug.cgi?id=25406 Richard Earnshaw changed: What|Removed |Added CC||rearnsha at gcc dot gnu.org --- Comment #1 from Richard Earnshaw --- Relocations wouldn't help if they were to another shared object. They would guarantee to be more than the offset range supported by those instructions. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/28031] New: iwmmxt2 assembly broken since f439988037a
https://sourceware.org/bugzilla/show_bug.cgi?id=28031 Bug ID: 28031 Summary: iwmmxt2 assembly broken since f439988037a Product: binutils Version: 2.36 Status: NEW Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: rearnsha at gcc dot gnu.org Target Milestone: --- Created attachment 13518 --> https://sourceware.org/bugzilla/attachment.cgi?id=13518&action=edit testcase. The attached assembly output (generated by gcc) no-longer assembles since revision f439988037a. Note this is a transfer of a bug reported on GCC. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101220 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/28031] iwmmxt2 assembly broken since f439988037a
https://sourceware.org/bugzilla/show_bug.cgi?id=28031 --- Comment #1 from Richard Earnshaw --- Commenting out the .fpu directive allows the test to assemble. Although iwmmxt2 is implemented in the co-processor space (and does conflict with the now deprecated FPA co-processor) it is not considered to be a fpu, so .fpu directives should not be affecting whether these instructions are enabled. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/28031] iwmmxt2 assembly broken since f439988037a
https://sourceware.org/bugzilla/show_bug.cgi?id=28031 Richard Earnshaw changed: What|Removed |Added Target||arm -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/28031] iwmmxt2 assembly broken since f439988037a
https://sourceware.org/bugzilla/show_bug.cgi?id=28031 --- Comment #3 from Richard Earnshaw --- Fixed on master so far. Affects releases back to 2.34. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/28031] iwmmxt2 assembly broken since f439988037a
https://sourceware.org/bugzilla/show_bug.cgi?id=28031 Richard Earnshaw changed: What|Removed |Added Version|2.36|2.34 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/28031] iwmmxt2 assembly broken since f439988037a
https://sourceware.org/bugzilla/show_bug.cgi?id=28031 Richard Earnshaw changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|--- |2.36.1 --- Comment #5 from Richard Earnshaw --- Fixed on master and binutils-2.36 branch. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/28078] arm: fails to build when using armv8 neon with dotprod extension
https://sourceware.org/bugzilla/show_bug.cgi?id=28078 Richard Earnshaw changed: What|Removed |Added CC||rearnsha at gcc dot gnu.org --- Comment #4 from Richard Earnshaw --- (In reply to Tamar Christina from comment #3) > Hi, > > >arm-unknown-linux-musleabihf-as -march=armv8.2-a+dotprod -mfpu=auto test.s > > Assembler messages: > > Error: unknown floating point format `auto' > > > > Error: unrecognized option -mfpu=auto > > hmm no it looks like we don't have -mfpu=auto at the assembler level yet, > only at the compiler level. > > But trying it locally it does seem like something has broken.. This is down to a change in binutils (gas); but that was to fix a different bug, so I don't think it can be reverted. I think the solution is that we need to re-issue the architecture extensions that relate to the FPU after emitting a .fpu directive. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/28078] arm: fails to build when using armv8 neon with dotprod extension
https://sourceware.org/bugzilla/show_bug.cgi?id=28078 Richard Earnshaw changed: What|Removed |Added Target||arm -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/28078] arm: fails to build when using armv8 neon with dotprod extension
https://sourceware.org/bugzilla/show_bug.cgi?id=28078 Richard Earnshaw changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #5 from Richard Earnshaw --- Moving this issue to GCC as the problem is the order in which the compiler emits the directives. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101723 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/28254] gas 2.36.1 fails to generate debugging information for aarch64 .S files
https://sourceware.org/bugzilla/show_bug.cgi?id=28254 Richard Earnshaw changed: What|Removed |Added CC||rearnsha at gcc dot gnu.org --- Comment #8 from Richard Earnshaw --- No, because that might lead to accidental security issues. Consider for example a stub of code that is intended to be copied somewhere else before it is executed, it might be mixed up with some data that could be 'executed' through an exploit if it were accidentally marked executable. It's far better that you do what has already been suggested and explicitly mark your section as executable than have the tools try to 'guess' something that might be unsafe. .text and .data are special. These have conventional uses so there's no guess work required. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/28078] arm: fails to build when using armv8 neon with dotprod extension
https://sourceware.org/bugzilla/show_bug.cgi?id=28078 --- Comment #6 from Richard Earnshaw --- For completeness, GCC has now been fixed on master and all maintained releases (back to gcc-9). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28848] [2.38 Regression] ld assertion fail ../../bfd/elf32-arm.c:14807
https://sourceware.org/bugzilla/show_bug.cgi?id=28848 Richard Earnshaw changed: What|Removed |Added CC||rearnsha at gcc dot gnu.org --- Comment #2 from Richard Earnshaw --- Yes, the attributes on crti.o are not as expected, but the reading process should sanitize them in that case, and if really broken emit a sensible user diagnostic. It should not generate an assertion failure at the point where it does. The correct fix, I think, is to convert the value 3 into value zero when reading the input object. This converts the deprecated value into the expected replacement. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28848] [2.38 Regression] ld assertion fail ../../bfd/elf32-arm.c:14807
https://sourceware.org/bugzilla/show_bug.cgi?id=28848 --- Comment #5 from Richard Earnshaw --- (In reply to Nick Clifton from comment #3) > Created attachment 13968 [details] > Proposed Patch > > Hi Richard, > > How about this patch ? > > I was unsure what should be done with the other potential values > for Tag_ABI_HardFP_use so I left them alone. > > Cheers > Nick I need to think about this a bit. The object file is arguably buggy in that it says that it uses hw fp, but doesn't say which version. But if we report an error (or a warning) we probably should do that for all input objects, not just the first on the list. Also, if we agree the object is buggy, we should probably have code in the assembler to fault that when the object is created. We should also warn if a deprecated tag value is picked, though I'm a little worried that might cause problems with version skew when used with older GCC releases - but perhaps tsktsk is good enough. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28848] [2.38 Regression] ld assertion fail ../../bfd/elf32-arm.c:14807
https://sourceware.org/bugzilla/show_bug.cgi?id=28848 --- Comment #7 from Richard Earnshaw --- (In reply to Nick Clifton from comment #6) > Fair enough. The thing that worries me is that the problematic file - > crti.o - comes from glibc and is going to affect the building of a lot of > projects. So whilst glibc can be fixed, that will take some time, and in > the meantime other peoples projects are stuck. A solution which will allow > builds to complete - even if it means ignoring a warning message from the > linker, is probably preferable to triggering an assert. It doesn't come from glibc, it comes from a debian-local patch to glibc, as I understand it. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/12198] New: SVC in thumb assembler forces M-profile attribute
http://sourceware.org/bugzilla/show_bug.cgi?id=12198 Summary: SVC in thumb assembler forces M-profile attribute Product: binutils Version: 2.21 (HEAD) Status: NEW Severity: normal Priority: P2 Component: gas AssignedTo: unassig...@sources.redhat.com ReportedBy: rearn...@gcc.gnu.org CC: mgret...@sourceware.org Target: arm-eabi Assemble the following testcase using the assemblers auto-selection of attributes mode (ie no CPU/arch selection on the command line, and no directives in sources). .thumb .global f .type f, %function f: svc 0xab bx lr arm-none-eabi-as -o t1.o t1.s arm-none-eabi-readelf -A t1.o Attribute Section: aeabi File Attributes Tag_CPU_arch: v6S-M Tag_CPU_arch_profile: Microcontroller Tag_THUMB_ISA_use: Thumb-1 Tag_DIV_use: Not allowed There's nothing in this file that forces this to M-profile. Indeed, it can even do this if the object file contains ARM assembly instructions. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/10810] Encoding for the Thumb MOV{S} instruction
http://sourceware.org/bugzilla/show_bug.cgi?id=10810 Richard Earnshaw changed: What|Removed |Added Status|NEW |RESOLVED CC||rearnsha at gcc dot gnu.org Resolution||FIXED --- Comment #1 from Richard Earnshaw 2011-05-11 17:11:59 UTC --- This appears to be fixed now: .syntax unified .thumb .cpu cortex-m3 movs r1, r2 mov r1, r2 movs r1, r8 $ /work/rearnsha/scratch/gnu/gcc/git/gas/as-new gas.s $ /work/rearnsha/scratch/gnu/gcc/git/binutils/objdump -d a.out a.out: file format elf32-littlearm Disassembly of section .text: <.text>: 0: 0011movsr1, r2 2: 4611mov r1, r2 4: ea5f 0108 movs.w r1, r8 -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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
