CFA: pseudo-reloc v2
Wed May 5 18:39:00 GMT 2010
On 05/05/2010 18:56, Christopher Faylor wrote:
> I like the idea but I have a few problems with this, some stylistic and
> some implementation.
Those all make sense to me, but I won't rework it yet until we've seen your
> I don't like keeping a list of "places we know we need to ignore" separate from
> the Cygwin DLL. That means that if there is something new added besides data/bss
> this function becomes obsolete.
> I think this argues for most of this functionality being moved to the
> Cygwin DLL itself so that an application gets improvements for free. I
> should have suggested that when this function first made its way into
> the libcygwin.a (or maybe I did and someone will enlighten me about why that
> won't work).
> I'll see I can come up with a proof-of-concept of what I'm talking about soon.
> Btw, don't we have to worry about data/bss for DLLs too? Is that
> handled by this change or is that not an issue?
We do have to worry and it is handled. This code gets linked statically
into each DLL and EXE, each instance referring just to its own pseudo-reloc
tables. The Cygwin DLL copies all the data and bss for both DLLs and EXEs (at
process attach time), then they all run their own pseudo-relocs (at first
thread attach time).
This only works /because/ the module is linked into each executable image
(i.e., DLL or EXE, and henceforth 'EI') separately. While we could move the
core code into the Cygwin DLL, we'd still have to have a statically linked
object in each EI to capture the module's definitions of
__RUNTIME_PSEUDO_RELOC_LIST__ and __RUNTIME_PSEUDO_RELOC_LIST_END__, and so
it's also a valid place to capture the local module's __data/bss_start/end_
definitions (as indeed is already done in _cygwin_crt0_common where it sets up
the per_process userdata structure).
So we could move the core __write_memory and do_pseudo_relocs routines into
the DLL, and adjust the code in _cygwin_crt0_common to pass the per_process
struct to _pei386_runtime_relocator which could pass it and the reloc list
start/end pointers through to the code in the DLL, and it could then be code
in the DLL that knows which memory ranges it copied and should avoid
Is that the kind of structure you were thinking of? The problem I saw with
any kind of approach based on actually knowing which ranges were actually
copied (as opposed to simply inferring that it was the data and bss sections
between their start and end labels) is that that all takes place in the parent
rather than the child, so how to communicate it to the child where the
relocating is taking place would be pretty tricky, I thought.
More information about the Cygwin-patches