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

[Toralf Lund]

Peter Barada wrote:

>>I now think the "eh frame" stuff discussed elsewhere has something to do 
>>with this, though. Simply put, I hadn't included *(.eh_fram*) in the 
>>linker script. If I do, I no longer get data in the "reserved" section, 
>>regardless of it's permission. The output size with *(.eh_fram*) 
>>included is different from both of the ones I got earlier (depending on 
>>"reserved" permissions), however, so I'm still not sure I understand 
>>exactly what is going on.
>>    
>>
>
>Generate a linker map and you should be able to see all of the
>sections of the files being linked in, and which sections they are
>ending up in....
>  
>
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.

- 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