cygwin-1.7, pseudo-reloc v2

[Earnie Boyd]

Quoting Charles Wilson <cygwin@cwilson.fastmail.fm>:

>
> On Fri, 23 Jan 2009 00:23:36 -0500, "Christopher Faylor" said:
>> On Fri, 23 Jan 2009 00:03:35 -0500, "Charles Wilson" wrote:
>>> Are there any plans to incorporate Kai Tietz' new pseudo-reloc v2
>>> runtime support into cygwin-1.7?
>>>
>>> http://sourceware.org/ml/binutils/2008-11/msg00004.html
>>> http://sourceware.org/ml/binutils/2008-11/msg00171.html
>>> http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/trunk/mingw-w64-crt/crt/pseudo-reloc.c?revision=518&view=markup
>>
>> Since this is the cygwin-developers list and not the cygwin list why
>> don't you humor us all a little by explaining how and where you think it
>> should be added?
>
> Okay. FWICT, how is fairly easy: we replace
> src/winsup/cygwin/lib/pseudo-reloc.c (and possibly
> src/winsup/mingw/pseudo-reloc.c, with associated mods to
> src/winsup/mingw/pseudo-reloc-list.c) with the version at the
> sourceforge link above (which was contributed to the public domain by
> Kai).
>

Since this involves MinGW I'm cross-posting to its developer list as 
well.  MinGW project has invited Kai to join forces with us.  He has 
yet to do so.  However, we would be willing to accept his patches if he 
were to properly submit those as patches.

I'm leaving this intact for the benefit of the mingw-dvlpr list.
> Why: From Kai's original post,
>> By the current implementation there are several problems I see.
>> a) Auto-imported variables do not work in all cases (e.g. structure 
>> field addresses, etc).
>> b) Each relocation leads to additional code needed.
> ? c) For 64-bit different relocation sizes are possible.
>> d) If the relocations are placed within custom read-only sections 
>> the pseudo-relocator produces an assertation by attempting to write 
>> to read-only addresses.
>
> While we (probably) don't care about the 64 bit issues as cygwin is
> still strictly a 32 bit beast, it appears as though Kai's new scheme
> allows (1) auto-import to work with "complex" data types, and (2) with
> relocs in read-only sections -- and the runtime component (that is,
> pseudo-reloc.c) supports both current pseudo-relocs (now called "v1")
> and the new style ("v2").
>
> But this will all need testing, of course -- especially to ensure that
> it doesn't break existing "v1" relocs. I just wanted to know -- since
> Kai's changes have now been committed to binutils CVS, although "v1"
> remains ld's default for 32 bit PE platforms -- if the new cygwin-1.7
> runtime component should support the new "v2" style relocations, so that
> we can play with ld's new --enable-runtime-pseudo-reloc-v2 option.
>
> Finally, there's this:
> On Mon, 3 Nov 2008 10:23:04 -0500, Christopher Faylor said:
>> I would be very interested in seeing this added for all PE targets.
>
>
> BTW, one part of Kai's change (now in binutils) changes this (for PE
> 32bit):
> -  link_info.pei386_runtime_pseudo_reloc = -1;
> +  link_info.pei386_runtime_pseudo_reloc = 1; /* Use by default version
> 1.  */
> That is, we will always act as tho --enable-runtime-pseudo-reloc were
> specified on the command line. This means the existing behavior ("-1" --
> where we DO pseudo-relocs, but warn about it unless the user explicitly
> specified --enable-runtime-pseudo-reloc) is changed to "just DO it and
> be quiet" unless the user specifically disables it.
>
> I guess it's about time we made that change, but there was no discussion
> of this particular bit.
>
> --
> Chuck
>

--
Earnie