This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

ARM Linker Address Map

Note: This was originally posted on 22nd November 2009 at http://forums.arm.com

Hi All,

Im new to this forum and pretty new to ARM development.
When Im compiling my SW in THumb mode the symbol names
in .map file shows Unaligned memory addresses(Eg: 0x225571).
But the symbol is actually placed in address aligned address(0x225570).
Can anybody explain why linker map shows unaligned address?

Thanks
  • Note: This was originally posted on 22nd November 2009 at http://forums.arm.com

    The least significant bit of the address is used by some ARM/Thumb instructions to determine the instruction set to use, e.g.

    [font="Lucida Console"]MOV r0,#0x21
    BX  r0[/font]

    Branches to address 0x20, and switches to Thumb state, whilst:

    [font="Lucida Console"]MOV r0,#0x20
    BX  r0[/font]

    Branches to address 0x20, and switches to ARM state.

    hth
    s.


    I guess the least significant bit of the destination address where the branching occurs represents the mode.
    This could even be a LSB of the Register where destination address is present(BLX Rm).

    My question is more about the starting address of a symbol/function code. Mostly this would be a PUSH instruction with most of the
    compilers. 
    Hope I made my question clear.

    Thanks.
  • Note: This was originally posted on 22nd November 2009 at http://forums.arm.com

    I think this amounts to the samething, consider:

    [font="Lucida Console"]LDR r0,datalabel
    BX r0
    ...
    datalabel DCD somefunc[/font]

    Here, the value inserted for [font="Lucida Console"]somefunc [/font] needs to have the LSB set if [font="Lucida Console"]somefunc [/font] is the symbol for a Thumb function. At which point the Thumb function code will reside at a halfword aligned location, whereas the symbol will be unaligned due to the least-significant-bit being set.

    hth
    s.


    Your explanation makes sense, provided a function is being jumped onto with change in mode.
    Or in otherwords if a Thumb function ever needs to be called from ARM code the function start address
    will have its LSB set.
    I compile all the code in Thumb mode but with interwork enabled.
    Is this the reason I see the symbol
    addresses in non-aligned addresses in Linker address map and in my debugger when I examine
    the memory, functions are all in aligned addresses.

    Thanks
  • Note: This was originally posted on 24th November 2009 at http://forums.arm.com

    > Is this the reason I see the symbol addresses in non-aligned addresses in Linker address map and in my debugger when I examine the memory, functions are all in aligned addresses

    Yes.

    For symbols in the linker view it is best if you view bits 31:1 as the address and bit 0 at a flag indicating "is in thumb".
  • Note: This was originally posted on 22nd November 2009 at http://forums.arm.com

    The least significant bit of the address is used by some ARM/Thumb instructions to determine the instruction set to use, e.g.

    [font="Lucida Console"]MOV r0,#0x21
    BX  r0[/font]

    Branches to address 0x20, and switches to Thumb state, whilst:

    [font="Lucida Console"]MOV r0,#0x20
    BX  r0[/font]

    Branches to address 0x20, and switches to ARM state.

    hth
    s.
  • Note: This was originally posted on 22nd November 2009 at http://forums.arm.com

    ...My question is more about the starting address of a symbol/function code....


    I think this amounts to the samething, consider:

    [font="Lucida Console"]LDR r0,datalabel
    BX r0
    ...
    datalabel DCD somefunc[/font]

    Here, the value inserted for [font="Lucida Console"]somefunc [/font] needs to have the LSB set if [font="Lucida Console"]somefunc [/font] is the symbol for a Thumb function. At which point the Thumb function code will reside at a halfword aligned location, whereas the symbol will be unaligned due to the least-significant-bit being set.

    hth
    s.