1. Home
  2. Embedded Programming
  3. Gnu LD generating bad addresses for PowerPC

Gnu LD generating bad addresses for PowerPC

I am using the GCC tools to generate code for a MPC563 PowerPC. Software versions (as reported by the -v options): AS GNU assembler version 2.15.91 (powerpc-eabi) using BFD version 2.15.91 20040904 LD GNU ld version 2.15.91 20040904

The program code is trivial: .global _BEGIN .section ".text"

_BEGIN: addis %r2, %r0, _BEGIN@ha addi %r2, %r2, _BEGIN@l

When the project is linked with .text at address 0x307000, this works correctly, generating the hex. longs 3C400030 38427000 which corresponds to _BEGIN at 0x307000, as expected.

Now here's the bug: If the object file is re-linked with .text at 0x308000, the following incorrect code is generated: 3C400031 38428000 which puts _BEGIN at 0x318000, not 0x308000 as it should be.

This is the linker script: MEMORY { RAM (w) : ORIGIN = $(RAMBASE), LENGTH = 0x3C00 } SECTIONS { ENTRY(_BEGIN) . = $(RAMBASE) ; .text ALIGN(4) : { *(.text) } >RAM }

with $(RAMBASE) set to 0x307000 or 0x308000 as required.

There is nothing "magic" about 0x307000, other addresses show the same effect. The rule seems to be that if address bit 0x00008000 is set, then 0x00008000 gets added to the address by the linker.

You can download the original source, Makefile, etc. from

formatting link

TIA

Reply to
David R Brooks
Loading thread data ...

Did you actually see this value (0x318000) appear in output/debugger ? ISTM the generated code is ok: addi will sign extend the immediate argument and the @ha adjusts for this, e.g.

lis r2, 0x0031 { r2 = 0x00310000 } addi r2, r2, 0x8000 { r2 = r2 + sign-extend(0x8000) = 0x00310000 + 0xffff8000 = 0x00308000 }

so the outcome should be as expected.

BTW: follow up to comp.sys.powerpc.tech

Rob Windgassen

Reply to
Rob Windgassen

:On Tue, 22 Feb 2005 18:19:51 +0800, David R Brooks wrote: : :> _BEGIN: :> addis %r2, %r0, _BEGIN@ha :> addi %r2, %r2, _BEGIN@l :> :> When the project is linked with .text at address 0x307000, this works :> correctly, generating the hex. longs :> 3C400030 :> 38427000 :> which corresponds to _BEGIN at 0x307000, as expected. :> :> Now here's the bug: :> If the object file is re-linked with .text at 0x308000, the following :> incorrect code is generated: :> 3C400031 :> 38428000 :> which puts _BEGIN at 0x318000, not 0x308000 as it should be. : :Did you actually see this value (0x318000) appear in output/debugger ? :ISTM the generated code is ok: addi will sign extend the immediate :argument and the @ha adjusts for this, e.g. : : lis r2, 0x0031 { r2 = 0x00310000 } : addi r2, r2, 0x8000 { r2 = r2 + sign-extend(0x8000) : = 0x00310000 + 0xffff8000 : = 0x00308000 } : :so the outcome should be as expected. : :BTW: follow up to comp.sys.powerpc.tech : : :Rob Windgassen

Reply to
David R Brooks

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.