Re: CFA: pseudo-reloc v2

["Charles Wilson" <cygwin at cwilson dot fastmail dot fm>]

Christopher Faylor wrote:
> On Wed, May 05, 2010 at 11:07:33PM -0400, Charles Wilson wrote:
>>I spent a lot of effort trying to synchronize our version of
>>pseudo_reloc.c with the mingw and mingw64 versions -- specifically so
>>that we could leverage Kai's v2 efforts.
>>
>>If we -- meaning cygwin -- move most of the guts into the cygwin DLL,
>>then ... we either
>>  (1) fork our version from the mingw[32|64] version permanently, and
>>lose the possibility of "easy" code sharing between the three projects, or
>>  (2) this portion of the code lives in both places (pseudo_reloc.c and
>>some-other-cygwin-dll-source-file), but is #ifdef'ed in pseudo_reloc.c
>>when compiled on cygwin, because there's this other identical copy over
>>in some-other-cygwin-dll-source-file.
>
> I kept the ifdef __CYGWIN__ stuff.  Moving the code into the DLL
> actually simplifies the Cygwin part quite a bit since you can use things
> like "winsup.h" and "small_printf".

Right...I have no argument that moving "stuff" into the DLL can simplify
the cygwin code, both the parts that end up "inside" the DLL and the
stuff that's left "outside" in pseudo_reloc.c.

But...if I understand correctly, doing this moves the "fix" for the
problem Dave identified into that internal code -- which means that the
mingw guys won't benefit from it, unless they re-implement it in the
"outside" code.  Hence: duplication of code -- and that's assuming we
continue to try and keep the various copies of pseudo_reloc in sync.

If we don't...well, then, there's no duplication of code between
winsup/cygwin/lib/pseudo_reloc.c and winsup/cygwin/some_file.cpp, but
there IS duplication (or would be, if the bug is to be fixed for mingw)
between winsup/cygwin/some_file.cpp and winsup/mingw/pseudo_reloc.c ==
mingw64/pseudo_reloc.c.  Plus, the three copies of pseudo_reloc.c would
diverge, complicating any future sharing.

>  And, my changes don't permute
> things as much as Dave's.

Wouldn't know. AFAICT, you haven't posted your patch yet. <g>

>  Dave's changes were not really MinGW
> friendly.

Right -- I don't believe Dave was thinking about MinGW at all.  I was
going to chime in about that just once in the thread...your message won
the raffle.

>>Yuck.  (I don't mind "losing" the effort I put in, because whatever
>>happens we now have v2 support.  But...why make it harder if somebody
>>in mingw-land invents v3?  Or make it harder on them, if WE do?)
> 
> And, why not make it so that potentially all that is required for v3
> support is a DLL upgrade rather than a rebuild?

Well, remember: if any given client is going to use v3 relocs, then it
must be compiled/linked with --enable-pseudo-relocs-v3 so that the image
actually /contains/ those kinds of pseudo relocation records.  So, you
can only "slipstream" improvements in an *existing* pseudo-reloc scheme
(e.g. v1 or v2) without recompiling the client; you can't magically
convert existing clients to a brand new scheme -- that always will
require recompilation.

In contrast, the current "everything lives in pseudo_reloc.c" system
means you can't even deliver improvements in an existing pseudo-reloc
scheme without recompiling the client.  And that will always be true for
mingw/mingw64.

--
Chuck