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

[Toralf Lund]

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