Linker mapfile shows strange addresses

[Hartmut Keller]

Hi,

I'm using an m68k-elf-ld linker (GNU ld version 2.14 20030612) and
relocating sections to a different load address with AT. As the linker
script file for doing this is not so easy to write, I'm often looking at the
mapfile generated by ld to verify that I'm doing everything correct. However
this mapfile often shows totally wrong values, or at least I can't interpret
them. For example look at the following snippet of a script file:


    ___FBUF_START = 0x00010000;

    ..flashinit :
    {
        *(.flashinit)
        *(.flashinitdata)
    } > FINIT


    _ROM_size = 0;
    _TEMP_address = ___FBUF_START;
    _reset_at = _TEMP_address;

    /* The reset section contains code which will be executed at
       reset time.  It should stay in ROM while the remainder of
       the code executes from RAM. */

    ..reset : AT( _reset_at )
    {
       ...
    }


This generates the following mapfile output:


                0x00010000                ___FBUF_START = 0x10000

..flashinit     0x00008000      0x1ba
 *(.flashinit)
 .flashinit     0x00008000      0x11a obj/dcu_prog.o
                0x00008000                _copy_to_flash
 *(.flashinitdata)
 .flashinitdata
                0x0000811a       0xa0 obj/dcu_prog.o
                0x00000000                _ROM_size = 0x0
----->          0x00010000                _TEMP_address = ___FBUF_START
----->          0x00032758                _reset_at = _TEMP_address

..reset         0x04000000      0x800 load address 0x00010000


It is strange that symbol "_reset_at" gets a totally different value than
"_TEMP_address", though one is assigend to the other. Nonetheless it seems
to work OK, because the ..reset section is correctly loaded at 0x10000 as
you can see from the last line. I can only assume that the mapfile info on
"_reset_at" is wrong. This is totally irritating as I think I can not trust
the values listed in the mapfile.

Two years earlier on a different project I had similar problems with a
powerpc-linux-ld (GNU ld version 2.11.92.0.12.3 20011121), so I ask myself
if no-one else has found this bug so far (which I can't believe). Or, what
is more likely, if I'm simply interpreting these values wrong.

Please help me to understand.

Best regards,

  Hartmut