Convert Linker Output to Binary File

[frank.ueberschar at dsa-volgmann.de]

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