Convert Linker Output to Binary File

[Ian Caddy]

Hi Frank,

When we converted over from 4.5 to 4.6 we needed to change our linkcmds 
file as there was a bunch of new things that were not included in our 
old linkcmds files.

One of these was how rodata changed with extra bits tacked on the back.

Our 4.5 linkcmds for rodata looked like this:

*(.rodata)

Our new 4.6 (and 4.7) linkcmds for rodata looked like this:

*(.rodata*)

Note the extra star at the end.

I do not know if this is your problem, but I remember back to when we 
did the conversion (we use a custom Coldfire 5307 BSP) I had issues like 
what you are describing.

Hope this helps.

regards,

Ian Caddy


frank.ueberschar at dsa-volgmann.de wrote:
>> you can use memory bank in the "linkcmds" file like this:
>>
>> the code   running in the zero address  is located in the start.s file
>> and start.s is compiled to start.o.
>>
>> MEMORY
>> {
>>     ram : ORIGIN = 0, LENGTH = 1M
>>     sram : ORIGIN = 0x03100000, LENGTH = 64K
>> }
>>
>> you can put the start.o in the "ram" memery bank and the others in the
>> "sram"  memory bank.
>> like this.
>>
>> SECTIONS
>> {
>>      .first:
>>      {
>>          start.o
>>      }>ram
> 
> This won't work because all objects are asserted to be
> in our 0x03100000 SDRAM Adress space. 
> 
> On Startup we are using a bootloader that copies all
> raw binary data stored in flash to sdram. The Bootloader 
> then jumps to the code now residing in sdram. So the
> startup code for the RTEMS C-Runtime has to be there. 
> 
> The code is running on our mcf5272 self customized board, 
> when having the linker produced a raw-binary file itself
> by adding OUTPUT_FORMAT (binary) to linkcmds. 
> 
> If we were missing this line (to prooduce a disassemble
> with objdump) then objcopy fails to convert the built 
> elf format into raw binary. (740kB -> 50MB)
> 
> ..below: 
> 
>>      .text:
>>     {
>>        *(.text)
>>     }>sram
>>
>> }
>>
>>
>>
>> 04 Jan 2007 20:30:48 UT, frank.ueberschar at dsa-volgmann.de
>> <frank.ueberschar at dsa-volgmann.de>:
>>> I am  bit confused with the following mapfile entry.
>>>
>>>
>>>  .rodata.str1.1
>>>                 0x0318b891      0x66f o-optimize/netcom.o
>>>                                 0x6e4 (size before relaxing)
>>>  .rodata.str1.1
>>>                 0x00000000        0x2 o-optimize/misc.o
> 
> 
> - When building RTEMS with -fno-merge-constants or when using 
>   OUTPUT_FORMAT (binary) we do not have the above output lines 
>   in the map file - there are a couple more of them even in the 
>   libraries. 
>   
>   (Could this be a bug in the linker as we never had this 
>    Problem when we were using the tools around RTEMS 4.5.1 ?)
> 
> 
> Thank you for your advice. 
> Frank
> 
> 
> 
> 
> 
> 
>>>  .rodata.str1.1
>>>                 0x0318bf00       0x9e o-optimize/desk.o
>>>  .rodata.str1.1
>>>                 0x0318bf9e      0x3d3 o-optimize/aspfunc.o
>>>                                 0x3f8 (size before relaxing)
>>>
>>> Having built an application with rtems-4.7 I cannot
>>> opjcopy the created .exe into a binary that is nearly
>>> as small as I expected. (50MB -> 700kB)
>>>
>>> The code will be running at 0x03100000. But there
>>> seems to be some object beeing used at 0x0 so that
>>> objcopy fills the gap with 50MB of zeros.
>>>
>>> I was wondering about the rodata.str1.1 section having
>>> adress 0x0 as the link-address (might be merged constants).
>>>
>>> Can someone give me a hint on how to get rid of the unneeded
>>> symbols so objcopy can generate an appropriate binary ?
>>>
>>>
>>>
>>> $(CC) ... -fno-merge-constants does not help because any
>>>            contributed library had to be recompiled)
>>>
>>> OUTPUT_FORMAT (binary) in fact produces a running binary
>>>            - but I like to keep always a disassemble which
>>>              itself needs the symbols for objdump.
>>>
>>>
>>> Happy new year,
>>> kind regards:
>>>
>>> Frank
>>>
>>> _______________________________________________
>>> rtems-users mailing list
>>> rtems-users at rtems.com
>>> http://rtems.rtems.org/mailman/listinfo/rtems-users
>>>
>>>
>>>
>>
>> -- 
>> Bai.Shaolin
>> Northeastern  University, ShenYang,China
>> +86-24-23897811
>>
> 
> 
> To: baishaolin at gmail.com
> Cc: rtems-users at rtems.org
> 
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
> 

-- 
Ian Caddy
Goanna Technologies Pty Ltd
+61 8 9221 1860