RFA: pseudo-relocations for pe targets

[Kai Tietz]

> On Tue, Nov 11, 2008 at 07:47:29AM -0800, Brian Dessent wrote:
> >Kai Tietz wrote:
> >
> >> Well, I thought about the noop version, but deceided not todo so. The
> >> problem is that __image_base__+0 is not necessarily writeable, but 
old
> >> relocator tries to add then zero there and may raise a PF. So I want 
to
> >
> >The case of the v1 runtime with a v2 list of relocs is just never going
> >to work anyway, so it's not worth trying to make it work.  Even if you
> >avoided the fault with it trying to fixup target=0, it's just going to
> >fault at the next step when it treats the 'fixup_sym/flags' fields as
> >what it thinks are the 'addend/target' fields of the next entry.
> >
> >> implement it by checking that the size for the entries modulo
> >> sizeof(pseudo_reloc_v1) is zero for v2 and check that the flags (the
> >> reloc-size) field has just values of 8,16,32,64. Otherwise version 
one is
> >> assumed.
> >
> >Checking the size doesn't really seem like all that great of an idea
> >given that sizeof(v2) is four words and sizeof(v1) is two words, so all
> >you can really tell here is that it's a v1 list if there happens to be
> >an odd number of entries.  In all other cases you can't tell anything
> >and so you're down to this flags heuristic.  Just assuming that you'll
> >never have a target that's a power of 2 seems really weak, especially 
if
> >in the future you need to extend the list of valid flags.
> >
> >I think the "first entry of v2 is a zeroed no-op" is a much better way
> >to go.
> 
> Or first entry zeroed, second entry version number.
> 
> cgf
> 

About this I thought too. I'll modify the patch accordingly to this and 
re-post it here (plus a pseudo-reloc.c variant for test).

Kai

|  (\_/)  This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.