[U-Boot] [PATCH v3] Switch from archive libraries to partial linking

[Albert ARIBAUD <albert.aribaud@free.fr>]

Le 19/11/2010 14:07, Reinhard Meyer a ?crit :
> Dear Albert,
>>
>> On 2010-11-19 13:38:00, Albert ARIBAUD wrote:
>>> Le 19/11/2010 13:33, Sebastien Carlier a ?crit :
>>>> Is it not possible to tell the linker to place a made-up 32 kB symbol
>>>> within the text section at address 0x40008000?  I am not familiar enough
>>>> with ld to tell whether there are restrictions for setting the absolute
>>>> address of a symbol that would disallow it in this case.
>>> You can force a symbol to reside at a given offset, but that will
>>> not make the linker "skip" that symbol when filling the output
>>> section, if that's what you meant.
>>
>> Yes, I was hoping the linker would first allocate space for
>> absolute-address symbols and then fill the gaps with the remaining
>> symbols in whatever order.
>>
>>> If you read up the binutils doc, you'll see that ld fills output
>>> sections based on a "location pointer" (the "dot") that simply moves
>>> on with each input section added -- no skipping, and no jumping from
>>> one region to another either.
>>
>> I see, thank you for pointing this out.  This specific behavior actually
>> seems quite essential to the interpretation of linker scripts, so there
>> is probably no hope for any change there.
>
> Have you tried something in the line of:
>
> /* Memory Definitions */
>
> MEMORY
> {
>    CODE (rx) : ORIGIN = 0x00000000, LENGTH = 0x0007E000
>    DATA (rw) : ORIGIN = 0x40000000, LENGTH = 0x00007A00
>    ENET (rw) : ORIGIN = 0x7FE00000, LENGTH = 0x00004000
> }
>
>
> /* Section Definitions */
>
> SECTIONS
> {
>
>    /* first section is .text which is used for code */
>
>    .text :
>    {
>      *startup2300.o (.text)		/* Startup code */
> 	*basicio.o (.text)			/* basic I/O */
>      *(.text)					/* remaining code */
>
>      *(.glue_7t) *(.glue_7)
>
>    }>CODE =0
>
>    . = ALIGN(4);
>
> ...

Those regions would most probably inflate the .bin because of the gap 
between the various MEMORY areas.

> *maybe* one can define several areas for CODE in the MEMORY section?

Afraid not. :/

Amicalement,
-- 
Albert.