Re: m68k-coff: Unused memory region included in output file?

[Toralf Lund <toralf at procaptura dot com>]

Peter Barada wrote:

> > Good idea. I haven't actually used that feature before, so I never 
> > thought of it. Anyhow, if I drop the eh_fram handling *and* make 
> > "reserved" writeable again, I get
> >
> > .eh_fram        0x00000000      0x1e0
> > .eh_fram        0x00000000      0x1e0 
> > /usr/lib/gcc/m68k-coff/3.4.2/m68000/libgcc.a(unwind-dw2-fde.o)
> >
> > which I guess explains a lot. Like I said, the way the file size changes 
> > is still a bit confusing, but I'm now thinking that once I get data at 
> > 0x00000000, the "gap" between that and the next section will also be 
> > included in the file (at least the plain binary variant), so that the 
> > size increase is equivalent to the size of the memory region, rather 
> > than the actual amount of data added.
> >    
>
> Now extract unwind-dw2-fde.o and do an 'objdump -h' on it to see what
> sections it has in it,
Maybe I will, but from what I've seen already it seems evident that the 
file only contains standard sections like .text and .data besides the 
.eh_fram.

> and modify your linker command file to make
> sure you tell the linker what to do with each section so they don't
> end up quietly getting dropped into the first section.
>  

> Look at some of the linker command files that came with the newlib
> source to get a rough idea of where they should go.
Actually, I checked them earlier, and they didn't give a clear idea of 
where .eh_fram belongs, or the different scripts seem to have different 
ideas, if you know what I mean.

- Toralf

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com