CFA: pseudo-reloc v2
Wed May 5 20:30:00 GMT 2010
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
>> 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
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
More information about the Cygwin-patches