Suppose you have an operating system that supports many different micro controller boards (RTEMS in our case). Each board needs a linker command file which supports it. The boards tend to come in various flavors. Some execute code from flash others copy the code and constant data from a flash into a ram during the system start. Some have a small and fast and a big and slow ram or a special purpose ram here and there etc. So currently we have many copy and paste linker command files that are only a little bit different. This causes a maintainance headache so the goal is to provide a basic linker command file for each architecture that is included in the board dependend linker command files. Example for a simple linker command base file (linkcmds.base): SECTIONS { .text : { /* Code and constant data */ } > TEXT_REGION .data : { /* Data */ } > DATA_REGION .bss : { /* Zero initialized memory */ } > BSS_REGION } Example for a board specific linker command file: MEMORY { ROM_REGION (RX) : ORIGIN = 0x10000000, LENGTH = 256M RAM_REGION (AIW) : ORIGIN = 0x20000000, LENGTH = 256M } INCLUDE linkcmds.base So now we have a problem to assign each region of the base file a region provided by the board. We need this flexibility due to the different memory structures of the various boards. A solution would be a new linker command file function: REGION_ALIAS (alias, region_name) With that the board specific linker command file would look like: MEMORY { ROM_REGION (RX) : ORIGIN = 0x10000000, LENGTH = 256M RAM_REGION (AIW) : ORIGIN = 0x20000000, LENGTH = 256M } REGION_ALIAS (TEXT_REGION, ROM_REGION) REGION_ALIAS (DATA_REGION, RAM_REGION) REGION_ALIAS (BSS_REGION, RAM_REGION) INCLUDE linkcmds.base This would make the region facility much more flexible.
Hi Sebastian, Why not use a pre-processor instead ? For example your board specific file could look like this: MEMORY { ROM_REGION (RX) : ORIGIN = 0x10000000, LENGTH = 256M RAM_REGION (AIW) : ORIGIN = 0x20000000, LENGTH = 256M } #define TEXT_REGION ROM_REGION #define DATA_REGION RAM_REGION #define BSS_REGION RAM_REGION #include "linkcmds.base" and where you would have "gcc -T <board-script> ..." as your command line you could use: cpp <board-script> <tmp-full-script> gcc -T <tmp-full-script> rm <tmp-full-script> The point being that there is no need to add any extra functionality to the linker, along with the possibility of introducing new bugs. Cheers Nick
Hi Nick, we could of course use the C pre-processor or a billion other tools to generate a linker command file, but the linker should do its job without the need of external tools. The linker has already the capability to gather its linker command file from various files via the INCLUDE function. So I guess that someone had in mind that you should be able to split the hole stuff into general and specific parts. One point against your single project solution is that this feature might be useful for other projects too. Lets consider a practical example for the PowerPC architecture: The MPC8313E RDB has a huge RAM of 128 MB and the MPC5566 EVB has only a small RAM of 128 kB but it can execute its code from a ROM. The only difference (except RAM and ROM dimensions) in the linker command files of these two boards is that in the first case the code section goes into the RAM region and in the second case it goes into the ROM region. With the current linker command file facilities you cannot provide a general part that may be used for both boards. So now you have the choice to generate it via external tools or enhance the linker command file facilities. The above example illustrates an every day problem for the linker if you work with various boards. So from my point of view we should enhance the linker. Have a nice day!
Yes or no? What happens if we implement this feature and provide a patch?
Subject: Re: New linker command file function: REGION_ALIAS Hi Sebastian, > Yes or no? Yes. > What happens if we implement this feature and provide a patch? Then we will review it and assuming that it is OK, it will be accepted into the sources. Cheers Nick
(In reply to comment #4) [...] > > What happens if we implement this feature and provide a patch? > > Then we will review it and assuming that it is OK, it will be accepted > into the sources. [...] Ok, but this will take a while.
Created attachment 3637 [details] Patch that adds the REGION_ALIAS() script function This is patch that implements the REGION_ALIAS() script function. Some notes: o Is stat_alloc() the right way to allocate name list entries? o I quoted the names in errors and warnings with `'. Is this the preferred way? o I removed the declaration of lang_memory_region_default(). I seems that this function is nowhere defined. o Is there some documentation available how to write test cases for the testsuite? I will add some documentation if the patch gets accepted.
Hi Sebastian, The patch looks good - thanks very much for persevering with this. In answer to your questions: * Yes stat_alloc() is the right function to use. * Quoting names like this is preferred. * You are correct, the prototype for lang_memory_region_default is redundant. * There is no separate documentation for writing testcases. But it is relatively simple to do by taking an already existing testcase (or two) and modifying them to suit your needs. So, in order to accept this patch, or rather an extended version of it, we will need: * A copyright assignment on file with the FSF for binutils contributions. * Documentation of the new feature in ld/ld.texinfo plus a one line description of it in ld/NEWS. * A testcase or two to make sure that it works, and continues to work as changes are made to the linker in the future. Cheers Nick
Created attachment 3752 [details] REGION_ALIAS implementation, documentation and test cases. The copyright assignment should be on file now.
Hi Sebastian, Thanks for the revised patch. I have applied it along with this changelog entry. Cheers Nick ld/ChangeLog 2009-03-02 Sebastian Huber <sebastian.huber@embedded-brains.de> * ldgram.y: Add support for REGION_ALIAS operator. * ldlang.c: Likewise. * ldlang.h: Likewise. * ldlex.l: Likewise. * NEWS: Mention the new feature. * ld.texinfo: Document the new feature. ld/testsuite/ChangeLog 2009-03-02 Sebastian Huber <sebastian.huber@embedded-brains.de> * ld-scripts/regions-alias-1.t: New file. * ld-scripts/regions-alias-2.t: New file. * ld-scripts/regions-alias-3.t: New file. * ld-scripts/regions-alias-4.t: New file. * ld-scripts/script.exp: Run region alias tests.
Hi Nick, thank you very much for your benevolence. Have a nice day!