RE: embedded system ld script issues

["Dave Korn" <dk at artimi dot com>]

> -----Original Message-----
> From: binutils-owner  On Behalf Of Bryce Schober
> Sent: 27 April 2004 18:30

> I'm trying to write my own ld script for use in an embedded 
> system, but 
> I'm having a hard time with a couple of things.  (I'm pretty much a 
> newbie with ld)
> 
> First, what does the memory help (malloc, etc) need from the 
> ld script?

  That entirely depends on how your implementation of malloc works.  It
might require you to define symbols in the linker script that it can refer
to later to know the amount of memory available.  Or your malloc
implementation might depend on something else in your BSP to test, measure,
deduce or infer the amount of memory.  You'll have to find out what library
code you're using and look at how it works.

> Second, how can I define a memory map (where sections of code / data 
> should go) in one place, to be used by source and in linkage?  I have 
> been using a .h header file which #defines several constants, but it 
> seems that those aren't visible symbols in the ld script.

  #defines (being plain text substitutions performed by the preprocesser)
don't actually create any output in the .o files, and since there's no
#include directive in linker scripts, you really shouldn't be surprised;
there's no mechanism by which the linker could possibly know about them.
(Actually, I suppose it could parse the debug information, but that's not so
much a can of worms as a massive vat of poisonous snakes, so we'll just skip
lightly over it...).

> What I want to do is define a memory map of my flash part in one file 
> and have the address and size of each section depend on the 
> used flash 
> part and be accessible both to source C code and for the 
> linking process.
> 
> An example memory map:
> 
> #if FLASHTYPE_NEW
>     #define FLASH_SIZE 0x00100000
>     #define FLASH_SECTOR_SIZE 0x00001000
> #endif
> #if FLASHTYPE_OLD
>     #define FLASH_SIZE 0x00040000
>     #define FLASH_SECTOR_SIZE 0x00000800
> #endif
> 
> /**************************************/
> #define BOOT_ADDR   0x00000000
> #define BOOT_SIZE   (BOOT_END-BOOT_ADDR)
> #define BOOT_END    0x00004000
> /**************************************/
> #define EEPROM_ADDR BOOT_END
> #define EEPROM_SIZE (2*FLASH_SECTOR_SIZE)
> #define EEPROM_END  (EEPROM_ADDR+EEPROM_SIZE)
> /**************************************/
> #define CODE_ADDR   EEPROM_END
> #define CODE_SIZE   (FLASH_SIZE-CODE_ADDR)
> #define CODE_END    (CODE_ADDR+CODE_SIZE)
> /**************************************/

  Basically, the functionality that you're looking for in the linker here is
given by the MEMORY command in linker scripts.  See 

http://sources.redhat.com/binutils/docs-2.12/ld.info/MEMORY.html#MEMORY

or your local copy of the docs.  However, it's an unfortunate limitation of
the linker at the moment that you can only specify the bases and sizes of
memory ranges as explicit constants in the linker scripts, not as any kind
of symbol or define.  (It's basically a weakness in the parser, but would
take a good deal of restructuring or some very nasty hacks to work round)

  Probably the solution that you'll need to adopt is one of

1) Prewrite a whole bunch of linker scripts, according to the different
memory layouts of the targets you're aiming at, and make your build system
responsible for a) communicating to your C code which layout it's aiming at
by using -D to define symbols on the command line and b) choosing the
corresponding linker script when it calls the linker,  

   or

2) Make your build system generate linker scripts on-the-fly somehow,
according to the decisions/definitions in the C code.

  There may be other effective solutions which escape me at the moment, but
either of those should be effective enough to be getting on with.


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....