How is . = 0xADDR different from using MEMORY?

How is . = 0xADDR different from using MEMORY?

[Rick Mann]

Hi. I've been trying to move from using . = 0xABCD1234 in my linker  
script to put sections in the right place, to using the MEMORY  
command. But it's not behaving as I would expect.

I have the following sections in the (working) script (there are more,  
but this should serve for the example):

SECTIONS
{
	. = 0x80008000;
	
	. = ALIGN(4);
	.text :
	{
		obj/start.o(.text);
		src/Interrupts.o(.text);
		
		. = ALIGN(4);
		__gVectorsStart = .;
		KEEP (obj/vectors.o(.text));
		__gVectorsEnd = .;
		
		. = ALIGN(4);
		*(.text);
	}

	. = ALIGN(4);
	.bss :
	{
		__bss_start = .;
		__bss_start__ = .;
		/* first the real BSS data */
		*(.bss)
		*(COMMON)

		/* and next the stack */
		. = ALIGN(4);

		/* allocate an 8kB stack */		
		. = . + 8 * 1024;

		__stack_end = .;
		__bss_end = .;
		__bss_end__ = .;
	}
	
	. = ALIGN(1024 * 1024);
	
	.frameBuffer :
	{
		__gFrameBufferSectionStart = .;
		*(.frameBuffer)
		__gFrameBufferSectionEnd = .;
	}
	
	. = ALIGN(16 * 1024 * 1024);
	
	.mmuTables :
	{
		*(.mmuTables)
	}
	
}



If I do this, I get what I would expect: a 16MB+-sized binary (because  
of the 16MB alignment of .mmuTables). If instead, I add this:

MEMORY
{
	dram (wx) :		org = 0x80008000,	len = 128M
	
	vectors (wx) :		org = 0x00000000,	len = 1M
	theCaddo (wx) :		org = 0x5C000000,	len = 32K
	bootRomData (rw) :	org = 0x5C008000,	len = 48K
	sram (wx) :		org = 0x5C014000,	len = 688K
	rom (rw) :		org = 0x5E000000,	len = 64K
	monitor (rwx) :		org = 0x80000000,	len = 32K
	
}

and append ">dram" to each section above, and remove the . =  
0x80008000 at the top, I get a 4 MB+ binary.

This is all in an effort to place my sections closer together in the  
image, but I'm not there yet. I just wanted to get the memory map part  
working correctly. Any idea what's going on?

TIA,
Rick

Re: How is . = 0xADDR different from using MEMORY?

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 2070 bytes --]

On Thursday 01 November 2007, Rick Mann wrote:
> Hi. I've been trying to move from using . = 0xABCD1234 in my linker
> script to put sections in the right place, to using the MEMORY
> command. But it's not behaving as I would expect.
>
> I have the following sections in the (working) script (there are more,
> but this should serve for the example):
>
> SECTIONS
> {
> 	. = 0x80008000;
>
> 	. = ALIGN(4);
> 	.text :
> 	{
> 		obj/start.o(.text);
> 		src/Interrupts.o(.text);
>
> 		. = ALIGN(4);
> 		__gVectorsStart = .;
> 		KEEP (obj/vectors.o(.text));
> 		__gVectorsEnd = .;
>
> 		. = ALIGN(4);
> 		*(.text);
> 	}
>
> 	. = ALIGN(4);
> 	.bss :
> 	{
> 		__bss_start = .;
> 		__bss_start__ = .;
> 		/* first the real BSS data */
> 		*(.bss)
> 		*(COMMON)
>
> 		/* and next the stack */
> 		. = ALIGN(4);
>
> 		/* allocate an 8kB stack */
> 		. = . + 8 * 1024;
>
> 		__stack_end = .;
> 		__bss_end = .;
> 		__bss_end__ = .;
> 	}
>
> 	. = ALIGN(1024 * 1024);
>
> 	.frameBuffer :
> 	{
> 		__gFrameBufferSectionStart = .;
> 		*(.frameBuffer)
> 		__gFrameBufferSectionEnd = .;
> 	}
>
> 	. = ALIGN(16 * 1024 * 1024);
>
> 	.mmuTables :
> 	{
> 		*(.mmuTables)
> 	}
>
> }
>
>
>
> If I do this, I get what I would expect: a 16MB+-sized binary (because
> of the 16MB alignment of .mmuTables). If instead, I add this:
>
> MEMORY
> {
> 	dram (wx) :		org = 0x80008000,	len = 128M
>
> 	vectors (wx) :		org = 0x00000000,	len = 1M
> 	theCaddo (wx) :		org = 0x5C000000,	len = 32K
> 	bootRomData (rw) :	org = 0x5C008000,	len = 48K
> 	sram (wx) :		org = 0x5C014000,	len = 688K
> 	rom (rw) :		org = 0x5E000000,	len = 64K
> 	monitor (rwx) :		org = 0x80000000,	len = 32K
>
> }
>
> and append ">dram" to each section above, and remove the . =
> 0x80008000 at the top, I get a 4 MB+ binary.

when you say "binary", do you mean ELF or binary ?

> This is all in an effort to place my sections closer together in the
> image, but I'm not there yet. I just wanted to get the memory map part
> working correctly. Any idea what's going on?

review the LMA's and VMA's as reported by `readelf -l`
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]