From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Fri, 19 Nov 2010 14:33:53 +0100 Subject: [U-Boot] [PATCH v3] Switch from archive libraries to partial linking In-Reply-To: <4CE676A6.10205@emk-elektronik.de> References: <20101115080950.GA26767@safe.home.local> <20101115105407.2A24714EA7E@gemini.denx.de> <20101117133056.GB23875@safe.home.local> <20101118214448.B8DC014EA7E@gemini.denx.de> <20101119080833.5DD9714EA7E@gemini.denx.de> <20101119111112.A53E214EA7E@gemini.denx.de> <4CE66FA8.9080008@free.fr> <4CE676A6.10205@emk-elektronik.de> Message-ID: <4CE67CC1.60803@free.fr> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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.