public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* embedded system ld script issues
@ 2004-04-27 17:49 Bryce Schober
  2004-04-27 17:55 ` Dave Korn
  2004-04-28 10:35 ` Sergei Organov
  0 siblings, 2 replies; 3+ messages in thread
From: Bryce Schober @ 2004-04-27 17:49 UTC (permalink / raw)
  To: binutils

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?

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.

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)
/**************************************/

-- 
Bryce Schober
Design Engineer
Dynon Avionics, Inc.
www.dynonavionics.com

^ permalink raw reply	[flat|nested] 3+ messages in thread

* RE: embedded system ld script issues
  2004-04-27 17:49 embedded system ld script issues Bryce Schober
@ 2004-04-27 17:55 ` Dave Korn
  2004-04-28 10:35 ` Sergei Organov
  1 sibling, 0 replies; 3+ messages in thread
From: Dave Korn @ 2004-04-27 17:55 UTC (permalink / raw)
  To: binutils

> -----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....
 


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: embedded system ld script issues
  2004-04-27 17:49 embedded system ld script issues Bryce Schober
  2004-04-27 17:55 ` Dave Korn
@ 2004-04-28 10:35 ` Sergei Organov
  1 sibling, 0 replies; 3+ messages in thread
From: Sergei Organov @ 2004-04-28 10:35 UTC (permalink / raw)
  To: binutils; +Cc: Bryce Schober

Bryce Schober <bryce.schober@dynonavionics.com> writes:
> 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?

Usually malloc needs some symbols describing starting address and size
of the memory area to be used by malloc to be defined. How those
symbols should be called is entirely defined by your malloc
implementation or an embedded OS if you are using some. 

> 
> 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.

You can abuse C preprocessor to be able to include your header(s) into
the linker files. The idea is to run your linker command file through
preprocessor before using it as an input file for the linker. Suppose
you've written file 'linker.cmd' containing #include and other C
preprocessor directives. You then can generate 'linker.lnk' command file for
the linker using, e.g.,

gcc -E -P -traditional -undef -x assembler-with-cpp linker.cmd > linker.lnk

-- 
Sergei.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2004-04-28  7:45 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-04-27 17:49 embedded system ld script issues Bryce Schober
2004-04-27 17:55 ` Dave Korn
2004-04-28 10:35 ` Sergei Organov

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).