Convert Linker Output to Binary File

[Joel Sherrill]

Try redoing your linker script based upon the default linker script
used by the target when linking.  Maybe that will highlight a problem.

You might also want to try the 4.7 binutils since they are newer. It might
have been a bug that got fixed.

If that doesn't help, ask on the binutils list for some help from a binutils
maintainer.  Make it clear that powerpc-rtems is functionally the same as
powerpc-elf.

Some of these binutils problems are pretty esoteric.

--joel

frank.ueberschar at dsa-volgmann.de wrote:
> Hi Ian, thanks a lot - but: 
>
>
>   
>> 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*)
>>     
>
> I did change. But thus I dont know why valid addresses of
> sections rodata.str1.1 intermix with adresses 0x0 
> in the map file. (This seems not to be an RTEMS specific
> Problem - as I can see until now - but a linker problem.) 
>
> In my opinion this is the reason for the convert "error". 
>
> Regards, Frank
>
>
>
>   
>> 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
>>>>>
>>>>>
>>>>>
>>>>>           
>> -- 
>> Ian Caddy
>> Goanna Technologies Pty Ltd
>> +61 8 9221 1860
>>
>>
>>     
>
>
> To: ianc at goanna.iinet.net.au
> Cc: rtems-users at rtems.org
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>