This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


>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, 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.

-- 
Peter Barada
peter@the-baradas.com

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]