Linking images at one address, but loading them at another.

[Richard Earnshaw]

> Hi Richard,
> 
> > > Right - the reason for this is that segments are mapped to
> > > sections via their VMA address not their LMA address.  The
> > > solution however, is simple.  Provide a second segment to hold the
> > > relocated .text segment, like this:
> > 
> > Except that then, surely this will create a segment that the loader
> > will try to download to the virtual address, which is exactly what
> > I'm trying to prevent -- I want it to download it to the low memory
> > region, even though it is intended for execution at the high
> > addresses.
> 
> Shouldn't the loader be loading the segment to is physical address
> (aka LMA) rather than its virtual address (aka VMA) ?

Well, the ELF spec that that the p_paddr is OS specific; I'll talk to the 
guys that wrote the loader, but I suspect their opinion would be 'no'.

> Basically I think that you are hosed.  Segments are mapped to sections
> based on their VMA addresses, and the BFD library when it has to
> rebuild the program headers after strip has run, will inspect this
> mapping to determine if there are orphaned sections.  (The BFD library
> does not have access to a linker map to allow it to customise the
> program header creation).

Well, I could make it do what I want if I could only make the PHDRS 
section work correctly.  I mentioned two problems, and the above only 
deals with one of them (I can force the p_vaddr field to be what is 
required, but I can't then put another segment directly after that, since 
there seems to be no way of doing symbolic positioning in the PHDRS's AT 
directive).

If I reduce the output to one loadable segment, eg with the script below, 
I run into another bug.  This time the linker dies with an invalid 
negative seek when trying to output the .debug_abbrev section

Taking the same example as this morning, but with the new linker script, 
we get

ld -T ldscript.sample t.o -o t
ld: final link failed: File truncated

and we find that the filepos field of the .debug_abbrev section is 
negative.  It seems that the PHDRS AT directive (or the AT directive for 
the bss segment) is messing with the positioning of the debug output.  I 
could probably forcibly discard the debug output, but I would like to use 
it to debug the image!

R.