This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Linking images at one address, but loading them at another.
- To: Nick Clifton <nickc at cambridge dot redhat dot com>
- Subject: Re: Linking images at one address, but loading them at another.
- From: Richard Earnshaw <rearnsha at arm dot com>
- Date: Fri, 26 Oct 2001 14:42:52 +0100
- cc: Richard dot Earnshaw at arm dot com, binutils at sources dot redhat dot com
- Organization: ARM Ltd.
- Reply-To: Richard dot Earnshaw at arm dot com
> 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.
PHDRS
{
headers PT_PHDR PHDRS ;
image PT_LOAD AT (0x10000) ;
}
SECTIONS
{
.lotext 0x10000 : { *(.lotext) } :image
.text (0xa0110000 + SIZEOF (.lotext)) :
AT ( LOADADDR(.lotext) + SIZEOF ( .lotext ) )
{
*(.text)
*(.glue_7t) *(.glue_7)
} :image =0
. = ALIGN(256) + (. & (256 - 1));
.data : AT ( LOADADDR(.text) + SIZEOF ( .text ) )
{
*(.data)
} :image
.bss : AT (LOADADDR(.data) + SIZEOF (.data))
{
*(.bss)
*(COMMON)
. = ALIGN(32 / 8);
} :image
. = ALIGN(32 / 8);
}
void highfunc(void);
void (*func)(void) = highfunc;
void start() __attribute__((section(".lotext")));
void start()
{
(*func)();
}
void highfunc()
{
}