This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: RFA: pseudo-relocations for pe targets
- From: Brian Dessent <brian at dessent dot net>
- To: Kai Tietz <Kai dot Tietz at onevision dot com>
- Cc: binutils <binutils at sourceware dot org>, Nick Clifton <nickc at redhat dot com>
- Date: Tue, 11 Nov 2008 06:56:09 -0800
- Subject: Re: RFA: pseudo-relocations for pe targets
- References: <OF3019FD18.632C01E2-ONC12574FE.004F9D56-C12574FE.004FFB78@onevision.de>
- Reply-to: binutils <binutils at sourceware dot org>
Kai Tietz wrote:
> as you may saw in prior comments (or by source code), this is exactly the
> reason why I introduced version 1 and version 2. And as I told before for
> 32-bit targets version 1 (the old pseudo-relocation fixup structure) is
Oh right. I saw the first hunk which sets
- link_info.pei386_runtime_pseudo_reloc = -1;
+ link_info.pei386_runtime_pseudo_reloc = 2; /* Use by default version
2. */
...and neglected that this was in pep.em not pe.em.
> prepare at the moment additionally a version of the pseudo-reloc.c file,
> which is able to choose the proper relocation type by itself, but there
> should be at the moment no need to change this for 32-bit!
I still am not clear how you would write a runtime relocator that can
detect whether it's been passed a v1 or a v2 list. Or is that what you
were implying with the part of the v2 spec about addend == flags == 0
being interpreted as a no-op? In other words, you're saying that the v2
list would distinguish itself by having as the first entry an element
with all zeros (as that would never naturally occur with a v1 list since
a pseudo-reloc is only required when addend != 0)?
Brian