New @ linker scripts

Reinhard Kager reinhard.kager@wtw-electronic.at
Tue Jun 17 11:42:00 GMT 2014


Hi nick

thanks a lot for your support. Works pretty good now :)

So I can use an USB mass storage stack now via 2 applications 
(bootloader and user application), this saves a lot of flash.

Thanks again
Reinhard

PS.: section file if somebody is interested

OUTPUT_ARCH(rx)
SECTIONS
{
     .fvectors 0xFFFFFFA0 : AT (0xFFFFFFA0)
     {
         KEEP(*(.fvectors))
     }
     .text 0xFFFF0100 : AT (0xFFFF0100)
     {
         *(P)
         *(EXCLUDE_FILE (*r_usb_*.o *ff.o *lowsrc.o  *diskio_usb.o 
*rsk.o) C)
         *(EXCLUDE_FILE (*libc.a:lib_a-strcmp.o) .text)
         *(EXCLUDE_FILE (*libc.a:lib_a-strcmp.o) .text.*)
         etext = .;
     }
     .rvectors :
     {
         _rvectors_start = .;
         KEEP(*(.rvectors))
         _rvectors_end = .;
     }
     .init :
     {
         *(.init)
         __preinit_array_start = .;
         *(.preinit_array)
         __preinit_array_end = .;
         __init_array_start = (. + 3) & ~ 3;
         *(.init_array)
         *(SORT(.init_array.*))
         __init_array_end = .;
         __fini_array_start = .;
         *(.fini_array)
         *(SORT(.fini_array.*))
         __fini_array_end = .;
     }
     .fini :
     {
         *(.fini)
     }
     .got :
     {
         *(.got)
         *(.got.plt)
     }
     .rodata :
     {
         *(.rodata)
         *(.rodata.*)
         *(C_1)
         *(C_2)
         _erodata = .;
     }

     .eh_frame_hdr :
     {
         *(.eh_frame_hdr)
     }
     .eh_frame :
     {
         *(.eh_frame)
     }
     .jcr :
     {
         *(.jcr)
     }
     .tors :
     {
         __CTOR_LIST__ = .;
         ___ctors = .;
         *(.ctors)
         ___ctors_end = .;
         __CTOR_END__ = .;
         __DTOR_LIST__ = .;
         ___dtors = .;
         *(.dtors)
         ___dtors_end = .;
         __DTOR_END__ = .;
         _mdata = .;
     }
     USB_STICK_SECTION 0x07800000 : AT (0x07800000)
     {
         *(.text)
         *(.text.*)
         *(C)
         *(USB_STICK_SECTION)
         *(const_USB_STICK_SECTION)
         _mdataUSB  = .;
     }
     .istack 0x00016000 : AT (0x00016000)
     {
         _istack = .;
     }
     .ustack 0x00014000 : AT (0x00014000)
     {
         _ustack = .;
     }
     .data 0x00005000 : AT (_mdata)
     {
         _data = .;
         *(.data)
         *(.data.*)
         *(EXCLUDE_FILE (*r_usb_*.o *ff.o *lowsrc.o *diskio_usb.o *rsk.o) D)
         *(D_1)
         *(D_2)
         _edata = .;
     }
     .gcc_exc :
     {
         *(.gcc_exc)
     }
     .bss :
     {
         _bss = .;
         *(.bss)
         *(.bss.*)
         *(EXCLUDE_FILE (*r_usb_*.o *ff.o *lowsrc.o *diskio_usb.o 
*rsk.o) COMMON)
         *(EXCLUDE_FILE (*r_usb_*.o *ff.o *lowsrc.o *diskio_usb.o *rsk.o) B)
         *(EXCLUDE_FILE (*r_usb_*.o *ff.o *lowsrc.o *diskio_usb.o 
*rsk.o) B_1)
         *(EXCLUDE_FILE (*r_usb_*.o *ff.o *lowsrc.o *diskio_usb.o 
*rsk.o) B_2)
         _ebss = .;
         _end = .;
     }
     usbData 0x00000001 : AT (_mdataUSB)
     {
         _dataUSB = .;
         *(D)
         _edataUSB = .;
     }
     usbRAM :
     {
         _bssUSB = .;
         *(COMMON)
         *(B)
         *(B_1)
         *(B_2)
         _ebssUSB = .;
     }
     usbSelector :
     {
         usbSelector = .;
         *(ram_USB_STICK_SECTION)
     }
     Reserved 0xFFFFF000 : AT (0xFFFFF000)
     {
         LastBlockEB00 = .;
     }
     USB_STICK_BOOT_SECTION 0xFFFF0000 : AT (0xFFFF0000)
     {
         USB_STICK_BOOT_SECTION = .;
     }
}

Am 13.06.2014 17:29, schrieb Nicholas Clifton:
> 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
>
>


-- 
Ing. Reinhard Kager, BSc
Forschung und Entwicklung
   
WTW electronic GmbH
Entwicklungszentrum Graz
Reininghausstraße 5/17
8020 Graz
Email:     reinhard.kager@wtw-electronic.at
Website:   www.wtw-electronic.at



More information about the Binutils mailing list