[Bug ld/13991] powerpc-rtems ld failure [regression]
http://sourceware.org/bugzilla/show_bug.cgi?id=13991 --- Comment #1 from Ralf Corsépius 2012-04-20 15:55:10 UTC --- I don't think this is a bug in binutils, but a bug in RTEMS. cf. http://www.rtems.org/pipermail/rtems-users/2012-April/009843.html -- 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
[Bug ld/13991] powerpc-rtems ld failure [regression]
http://sourceware.org/bugzilla/show_bug.cgi?id=13991 --- Comment #2 from Joel Sherrill 2012-04-20 16:13:42 UTC --- (In reply to comment #1) > I don't think this is a bug in binutils, but a bug in RTEMS. > > cf. http://www.rtems.org/pipermail/rtems-users/2012-April/009843.html I respectfully think you are completely wrong. That change is a hack in the linker script to ignore the start address in __rtems_start that in the linked executable. It may be zero on some of the BSP variants using this linker script but it is a hack. This linker script and procedure has been in RTEMS since around 1999. The file only has 3 changes in that entire time. http://git.rtems.org/rtems/log/c/src/lib/libbsp/powerpc/shared/bootloader/ppcboot.lds The hack may be a work around but ld broke. -- 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
[Bug ld/13991] powerpc-rtems ld failure [regression]
http://sourceware.org/bugzilla/show_bug.cgi?id=13991 --- Comment #3 from Ralf Corsépius 2012-04-20 16:24:25 UTC --- (In reply to comment #2) > (In reply to comment #1) > > I don't think this is a bug in binutils, but a bug in RTEMS. > > > > cf. http://www.rtems.org/pipermail/rtems-users/2012-April/009843.html > > I respectfully think you are completely wrong. That change is a hack in the > linker script to ignore the start address in __rtems_start that in the linked > executable. It may be zero on some of the BSP variants using this linker > script > but it is a hack. My understanding of what is happening is RTEMS's linker script is accessing an _uninitialized_ symbol, something newer binutils seeming do not allow anymore. What my "hack" (I call it a fix to a defect in this linkerscript) is to conditionally initialize it to 0, if it's unused. The only change this does is to make an implicit initialization to 0 explict. > This linker script and procedure has been in RTEMS since around 1999. The file > only has 3 changes in that entire time. From what I can gather, binutils has changed its behavior. > http://git.rtems.org/rtems/log/c/src/lib/libbsp/powerpc/shared/bootloader/ppcboot.lds > > The hack may be a work around but ld broke. No, binutils has changed behavior and RTEMS is victim of this behavioral change. -- 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
[Bug binutils/14006] New: objdump fails to disassemble first instruction of function (arm-none-eabi, function-sections)
http://sourceware.org/bugzilla/show_bug.cgi?id=14006 Bug #: 14006 Summary: objdump fails to disassemble first instruction of function (arm-none-eabi, function-sections) Product: binutils Version: 2.22 Status: NEW Severity: normal Priority: P2 Component: binutils AssignedTo: unassig...@sourceware.org ReportedBy: w...@.org Classification: Unclassified Created attachment 6357 --> http://sourceware.org/bugzilla/attachment.cgi?id=6357 sample .o file, and C source which generated it Sometimes "objdump -d" fails to disassemble the first instruction of a function, printing it instead as ".word ": Disassembly of section .text.adc_lld_init: : 0:e59f1004 .word0xe59f1004 4:e3a4 movr0, #4 8:eafe b0 c: .word0x In this case the word at offset 0 should have been disassembled as something like "ldr r1, [pc, #4]". As far as I can tell the bug doesn't depend on what the first instruction is; it only affects the first instruction, not the rest of the function; and only with code compiled with -ffunction-sections. (Possibly only if the preceding function/section ended with a literal pool? Maybe objdump's code vs. data tracking is one word out of sync?) Tested with objdump from binutils-2.22 directly from gnu.org, as well as binutils 2.21.53.0.1.20110716 compiled via MacPorts, on an x86_64 MacOSX 10.6 machine. They behave the same. I've attached a tarfile with an .o file reproducing the problem, a minified .i file which produced that .o file, and a transcript of compiling & objdumping & getting the erroneous output. -- 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
