1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

Gnu LD generating bad addresses for PowerPC

Discussion in 'Embedded' started by David R Brooks, Feb 22, 2005.

  1. 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
    http://members.iinet.net.au/~daveb/buffer/fault.zip

    TIA
     
    David R Brooks, Feb 22, 2005
    #1
    1. Advertisements

  2. 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
     
    Rob Windgassen, Feb 22, 2005
    #2
    1. Advertisements

  3. Thanks Rob. Yes, I see it now (egg on face dept. :)
    I had looked at a static disassembly of the code, & noticed the
    difference from the compiler output. I had forgotten that addi does
    sign extension.


    :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
     
    David R Brooks, Feb 23, 2005
    #3
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.