CFA: pseudo-reloc v2

Dave Korn
Wed May 5 19:29:00 GMT 2010

On 05/05/2010 20:13, Christopher Faylor wrote:

> Yeah, I realized that two seconds after sending the message.  However,
> is this particular problem really an issue for DLLs?  DLLs should get
> their data/bss updated after _pei386_runtime_relocator() is called.  So
> it seems like you'd get the same thing being written twice.  It's not
> optimal but it shouldn't be fatal.
> The program's data/bss is different since that gets copied during DLL
> initialization and before _pei386_runtime_relocator() is (was) called.  So
> I could see how it could be screwed up.

  Ah, right; I wasn't looking at how much later the dll sections got copied, I
just figured the safest and consistent solution was just to treat everything
the same.

> That's basically it and I have it more-or-less coded but I haven't
> finished thinking about DLLs.  Maybe that's more complication than is
> warranted.  I have to do more research there.  We could, and I think
> should, put most of the code in pseudo_reloc.c in cygwin1.dll, though,
> rather than duplicate it in every source file.

  Yeh, the only thing we need in the source file is to capture the module's
idea of its section start/end pointers, as we already do in the per_process;
we could consider passing pointers to the pseudo-relocs in that as well, but
horrible backward-compatibility problems could arise.  It would make sense to
inline the remnants of _pei386_runtime_relocator into _cygwin_crt0_common and
do away with the pseudo-reloc.c file altogether.

> This information is all recorded for fork() so it should be doable.  It is
> more complicated to do it outside of the program but, like I said, it allows
> us to fix problems by a new release of the DLL rather than telling people
> "You must relink your program".

  Yeh.  Unfortunately it's too late to help with this time, but it would help
any future problem (so long as it didn't require us to capture additional data
in the lib/ part of the executable but could be fixed with what we were
already passing to the Cygwin DLL).


More information about the Cygwin-patches mailing list