CFA: pseudo-reloc v2
Wed May 5 23:28:00 GMT 2010
On 05/05/2010 21:30, Christopher Faylor wrote:
> 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?
http://cygwin.com/ml/cygwin/2010-04/msg00957.html comes with a couple of
testcases attached, although you can only be sure they've worked by running
them and seeing that no .stackdump file was generated in your $CWD.
> Chuck? Do you have anything I could use to test what I did?
There were some fork-related testcases in the original thread, but I didn't
refer back to them when I was revising this, so they're probably worth verifying:
> 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.
That bit worries me - even adding a single pointer in a place where there
would never have been a field before caused us enough trouble! But, it's
probably the right thing to do; it's the defined mechanism for conveying
image-specific information from the module to the cygwin dll.
> 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.
Changing per_process was not as easy as I had hoped when I did it!
> 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().
Re-ordering startup is the thing I didn't want to approach. The separation,
serialisation and ordering between process attach and first thread attach is
probably as reliable as anything we could hope for though.
> 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
Well, as long as it works it must make sense; it's just a matter of which we
figure is more long-term reliable and maintainable: your approach depends on
inferences about which things happen in which order during startup, mine
depends on inferences about which sections of the EI get copied from the
parent during a fork. So, this post is a commentary, rather than an objection.
More information about the Cygwin-patches