CFA: pseudo-reloc v2

Dave Korn
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? 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
> _pei386_runtime_relocator().

  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 mailing list