* How is . = 0xADDR different from using MEMORY?
@ 2007-11-02 1:03 Rick Mann
2007-11-02 1:18 ` Mike Frysinger
0 siblings, 1 reply; 2+ messages in thread
From: Rick Mann @ 2007-11-02 1:03 UTC (permalink / raw)
To: binutils
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
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: How is . = 0xADDR different from using MEMORY?
2007-11-02 1:03 How is . = 0xADDR different from using MEMORY? Rick Mann
@ 2007-11-02 1:18 ` Mike Frysinger
0 siblings, 0 replies; 2+ messages in thread
From: Mike Frysinger @ 2007-11-02 1:18 UTC (permalink / raw)
To: binutils; +Cc: Rick Mann
[-- 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 --]
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2007-11-02 1:18 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-11-02 1:03 How is . = 0xADDR different from using MEMORY? Rick Mann
2007-11-02 1:18 ` Mike Frysinger
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).