VMA != LMA with gnu ld?

[Lewin A.R.W. Edwards]

I'm still having troubles trying to get an executable linked with a section
that has LMA != VMA :( Using binutils 2.10.

What I want to do is have an embedded vector table inside my program. (My
program gets loaded at 0x02000000; it needs to copy its own vector table
into low-memory). I declare it as a separate section inside one of my
assembly files:

.section .ram_vectors
.code 32
.align 4
.globl vectors
vectors:
b reset_handler
b undefined_handler
b swi_handler
b prefetch_handler
b abort_handler
nop
b irq_handler
b fiq_handler

So far, so good. Now I add this fragment to my linker script just after the
.text section, so that the code assembled at ram_vectors is correctly ORGed,
yet still gets emitted into the final executable alongside the other code:

.ram_vectors . : AT (0)
{
*(.ram_vectors);
}

But the LMA and VMA are the same! Here is the output of arm-elf-objdump:

Idx Name Size VMA LMA File off Algn
0 .text 000014c1 02000000 02000000 00008000 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .ram_vectors 0000004f 020014c1 020014c1 00009510 2**4
CONTENTS, READONLY
2 .data 00000000 02001510 02001510 00009510 2**0
CONTENTS, ALLOC, LOAD, DATA
3 .bss 000002a0 02001510 02001510 00009510 2**4
ALLOC
4 .debug_abbrev 000002c4 020017b0 020017b0 0000955f 2**0

Worse, when I convert to binary with arm-elf-objcopy -O binary, the
.ram_vectors section is just lost (I guess because it isn't flagged as
ALLOC,LOAD, but how do I get it loaded?).

Any ideas on how to achieve what I need to achieve? I know I could assemble
the vectors section as a separate program and include it as binary (then
poke in jump addresses before loading it into low memory), but that is
REALLY kludgey! It should surely be possible for me to assemble the vectors
as a separate section with LMA != VMA, AND have that output to the ROMmable
binary.

--
-- Lewin A.R.W. Edwards (Embedded Engineer)
Personal: http://www.larwe.com/ and http://www.zws.com/
Work: http://www.digi-frame.com/

[Michael Schmid]

"Lewin A.R.W. Edwards" schrieb:

Hi,

I think the problem You have doesn't depend on binutils 2.10. I'm using them and
I'm also doing LMA!=VMA because of my initialised data segment. Here is my
linker description file. The .rdata segment should be of interest for you.

--------------------------------------------------------------------------------------------------

/* All important constants */

_FLASH_BASE = 0x01000000;
_FLASH_SIZE = 1M;
_FLASH_END = _FLASH_BASE + _FLASH_SIZE;

_ISRAM_BASE = 0x00000000;
_ISRAM_SIZE = 4K;
_ISRAM_END = _ISRAM_BASE + _ISRAM_SIZE;

_ESRAM_BASE = 0x02000000;
_ESRAM_SIZE = 256K;
_ESRAM_END = _ESRAM_BASE + _ESRAM_SIZE;

/* Used Memory and Locations */
MEMORY { flash(R) : ORIGIN = 0x01000000, LENGTH = 1M }
MEMORY { int_ram(RW) : ORIGIN = 0x00000000, LENGTH = 4K }
MEMORY { ext_ram(RW) : ORIGIN = 0x02000000, LENGTH = 256K }

/* We begin at _start */
ENTRY(_start)

/* Now the memory-map */
SECTIONS {

/* We start in the Flash */
. = _FLASH_BASE;

/* In the Flash we have a text segment which has to fit in our flash */
.text _FLASH_BASE : {
*(.text)
*(.rodata)
} >flash

/* Leave the room free for Initialvalues of .data */
_rdata_start = . ;

/* Let's start with the external SRAM */
. = _ESRAM_BASE;

/* The original .data section is now divided in two parts, */
/* .rdata in flash containing the initial values and */
/* .wdata in external SRAM for use of variables */
/* crt0.S copies the initial values to SRAM at the beginning */
_wdata_start = .;
.rdata _ESRAM_BASE : AT( _rdata_start ) {
*(.data)
} > ext_ram
_wdata_end = .;
_rdata_end = _rdata_start + SIZEOF(.rdata);

/* After this we have the .bss Segment in SRAM */
.bss : {
_bss_start = .;
*(.bss)
_bss_end = .;
end = .;
_end = .;
__end = .;
} > ext_ram

/* The memory from _FREE_MEM to _ESRAM_END is used by the stack */
_FREEMEM = .;

/* DWARF debug sections.
Symbols in the DWARF debugging sections are relative to the beginning
of the section so we begin them at 0. */
/* DWARF 1 */
.debug 0 : { *(.debug) }
.line 0 : { *(.line) }
/* GNU DWARF 1 extensions */
.debug_srcinfo 0 : { *(.debug_srcinfo) }
.debug_sfnames 0 : { *(.debug_sfnames) }
/* DWARF 1.1 and DWARF 2 */
.debug_aranges 0 : { *(.debug_aranges) }
.debug_pubnames 0 : { *(.debug_pubnames) }
/* DWARF 2 */
.debug_info 0 : { *(.debug_info) }
.debug_abbrev 0 : { *(.debug_abbrev) }
.debug_line 0 : { *(.debug_line) }
.debug_frame 0 : { *(.debug_frame) }
.debug_str 0 : { *(.debug_str) }
.debug_loc 0 : { *(.debug_loc) }
.debug_macinfo 0 : { *(.debug_macinfo) }
/* SGI/MIPS DWARF 2 extensions */
.debug_weaknames 0 : { *(.debug_weaknames) }
.debug_funcnames 0 : { *(.debug_funcnames) }
.debug_typenames 0 : { *(.debug_typenames) }
.debug_varnames 0 : { *(.debug_varnames) }
.stack 0x80000 : { _stack = .; *(.stack) }
/* These must appear regardless of . */

}

--------------------------------------------------------------------------------------------------

And here is the according result:

RELEASE_OBJ/mc_uc.elf: file format elf32-littlearm

Sections:

Idx Name Size VMA LMA File off Algn

0 .text 0001186d 01000000 01000000 00008000 2**2

CONTENTS, ALLOC, LOAD, READONLY, CODE

1 .glue_7t 00000000 01011870 01011870 00019870 2**2

CONTENTS, ALLOC, LOAD, READONLY, CODE

2 .glue_7 00000000 01011870 01011870 00019870 2**2

CONTENTS, ALLOC, LOAD, READONLY, CODE

3 .rdata 000007e4 02000000 01011870 00020000 2**2
CONTENTS, ALLOC, LOAD, DATA
4 .bss 0000127c 020007f0 020007f0 000207f0 2**4
ALLOC
5 .debug_aranges 00000740 00000000 00000000 000207f0 2**0
CONTENTS, READONLY, DEBUGGING
6 .debug_pubnames 000014a4 00000000 00000000 00020f30 2**0
CONTENTS, READONLY, DEBUGGING
7 .debug_info 00023068 00000000 00000000 000223d4 2**0
CONTENTS, READONLY, DEBUGGING
8 .debug_abbrev 00003be9 00000000 00000000 0004543c 2**0
CONTENTS, READONLY, DEBUGGING
9 .debug_line 0000d1ec 00000000 00000000 00049025 2**0
CONTENTS, READONLY, DEBUGGING
10 .stack 00000000 00080000 00080000 00056211 2**0
CONTENTS

--------------------------------------------------------------------------------------------------

By the way maybe someone could tell me the meaning of all the dwarf debugging
stuff in the linker script (I have copied it from another script without knowing
what I've done :-).

Regards,

Michael Schmid
mlsc...@iis.fhg.de

[Jonathan Larmour]

In article <RgUv6.575$aV2.2...@typhoon2.ba-dsg.net>,

Lewin A.R.W. Edwards <la...@larwe.com> wrote:
>I'm still having troubles trying to get an executable linked with a section
>that has LMA != VMA :( Using binutils 2.10.
>

>[snip]

>Worse, when I convert to binary with arm-elf-objcopy -O binary, the
>.ram_vectors section is just lost (I guess because it isn't flagged as
>ALLOC,LOAD, but how do I get it loaded?).

I think this is the cause of your problems - without being marked as
ALLOC/LOAD, the linker probably doesn't bother setting VMA != LMA.

Use:
.section ".ram_vectors","ax"

Jifl
--
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

[Lewin A.R.W. Edwards]

> >Worse, when I convert to binary with arm-elf-objcopy -O binary, the
> >.ram_vectors section is just lost (I guess because it isn't flagged as
> >ALLOC,LOAD, but how do I get it loaded?).
>

> .section ".ram_vectors","ax"

Thanks, Jonathan! This was the answer.