Re: CFA: pseudo-reloc v2

[Christopher Faylor <cgf-use-the-mailinglist-please at cygwin dot com>]

On Wed, May 05, 2010 at 08:48:28PM +0100, Dave Korn wrote:
>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).

I have something written now.  I'll dig through the cygwin archives to
see if I can find the original message which started this but are there
other test cases that I could use to verify that I caught all of the
code paths in the DLL?

Chuck?  Do you have anything I could use to test what I did?

What I did:

1) Move pseudo-reloc.c out of lib and into the dll (making
it a c++ file in the process).

2) Record the three values needed by _pei386_runtime_relocator in the
per_process structure.

3) Modify _pei386_runtime_relocator() to take a per_process * argument
and to check that the api of the per_process structure supports the
additional three values.

4) For fork call _pei386_runtime_relocator() before the copy of the program's
data/bss in child_info_fork::handle_fork().

5) For non-fork, call _pei386_runtime_relocator() in dll_crt0_1().

6) For dll's, call _pei386_runtime_relocator() in dll_list::alloc().

I haven't added any optimizations to make this implementation avoid
copying the data/bss but that is doable using Dave's technique.  It
just isn't needed now since the fork data copy should always trump
_pei386_runtime_relocator().

cgf