From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31835 invoked by alias); 27 Apr 2004 17:49:16 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 31786 invoked from network); 27 Apr 2004 17:49:15 -0000 Received: from unknown (HELO NUTMEG.CAM.ARTIMI.COM) (217.40.111.177) by sources.redhat.com with SMTP; 27 Apr 2004 17:49:15 -0000 Received: from mace ([192.168.1.25]) by NUTMEG.CAM.ARTIMI.COM with Microsoft SMTPSVC(6.0.3790.0); Tue, 27 Apr 2004 18:47:47 +0100 From: "Dave Korn" To: Subject: RE: embedded system ld script issues Date: Tue, 27 Apr 2004 17:55:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In-Reply-To: <408E98AA.3080807@dynonavionics.com> Message-ID: X-OriginalArrivalTime: 27 Apr 2004 17:47:47.0515 (UTC) FILETIME=[C07DB8B0:01C42C7F] X-SW-Source: 2004-04/txt/msg00735.txt.bz2 > -----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....