This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


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: RFA: pseudo-relocations for pe targets


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


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