This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: New @ linker scripts
- From: Nicholas Clifton <nickc at redhat dot com>
- To: Reinhard Kager <reinhard dot kager at wtw-electronic dot at>, binutils at sourceware dot org
- Date: Fri, 13 Jun 2014 16:29:15 +0100
- Subject: Re: New @ linker scripts
- Authentication-results: sourceware.org; auth=none
- References: <53997BB8 dot 2030304 at wtw-electronic dot at> <53997C1C dot 9010003 at wtw-electronic dot at>
Hi Reinhard,
i am pretty new in linker scripts
Welcome to the world of linkers...
specific section. If I do so, i get a "multiple
definition of" error from the linker for my function which is in the uart.o
mySection 0x07800000 : AT (0x07800000)
{
uart.o
*(mySectionFunctions)
}
.text 0xFFFF0100 : AT (0xFFFF0100)
{
*(.text)
*(.text.*)
*(P)
etext = .;
}
This is because the "*(.text)" is matching the .text section in the
uart.o file which has already been allocated to the mySection section.
Fortunately there is a simple solution - exclude it - like this:
.text 0xFFFF0100 : AT (0xFFFF0100)
{
*(EXCLUDE_FILE (usrt.o) .text)
*(EXCLUDE_FILE (uart.o) .text.*)
*(P)
etext = .;
}
Another question is about archive files. Can i map this at once in a
section or do I have to get the .o files and map all of them?
You can map them all at once in a section. Note - normally you do not
need to reference archives in a linker script. Selected contents of an
archive are automatically pulled in by the linker as they are needed in
order to resolve unresolved references. If you do need to refer to an
archive however you can do so using a colon character as in:
lib:file
refers to a file called "file" inside an archive called "lib". Or:
lib:
refers to the entire contents of an archive called "lib".
So, for example:
.mysection { lib:(.text) }
will place all of the code (but not the data) from an archive called
"lib" into a section called .mysection.
I thought gcc is using .text for function code and .rodata for read only
const data. But there is also data which is marked as C in the map file.
Blame Renesas - it is their fault. Their tools use sections called P
for program code, C for read-only data, D for writeable data and B for
uninitialised data. So in order to be compatible with Renesas tools
gcc, by default, uses these section names. There are command line
options to change this however.
Bizarrely if i map a function via an attribute into a section, the C
data for this function (I guess this are jumpTables for example of
switch statements) stay in the C section. So I have to map this again
manually, like this?
mySection 0x07800000 : AT (0x07800000)
{
uart.o
uart.o (C)
*(mySectionFunctions)
}
This would be a bug... :-)
Feel free to create a gcc bug report for the problem and maybe the RX
port maintainer will fix it. If not you can always ping me...
Cheers
Nick