Re: Relocation patch for cygwin

[Charles Wilson]

On 10/5/2011 8:10 AM, Bruno Haible wrote:
> Charles Wilson wrote:
>> The problem is, it can really cause issues for "the rest of cygwin" if
>> an app uses the Win32 API "behind cygwin's back". 
>
> I understand all that. I'm only saying that
>   - My need was to have the file name behind one particular address in
>     the current process.
>   - The Cygwin API only allows me to get _all_ file names behind all
>     addresses across the entire current process, and this is slow.
>   - It would be useful to have a Cygwin API that gives me the file
>     file name behind one particular address in the current process.
>     This should not be that slow.

That sounds like a job for
        cygwin_internal (cygwin_getinfo_types t, ...)

I've hacked up a patch to do this (for the current process) within
cygwin.  Looks like this:

        unsigned long
        cygwin_internal (CW_GET_MODULE_PATH_FOR_ADDR,
                         uintptr_t addr,
                         PWCHAR    buf,
                         size_t    buflen);

returns 0 on success, nonzero on error (or if addr is unmapped, or
cygwin can't figure out where the given addr belongs). I'll post the
patch to cygwin-patches once I've finished testing.  'Course, then we
have to see what the cygwin folks say about it...

In any event, even if it IS accepted, it still wouldn't be available unless
        CW_GET_MODULE_PATH_FOR_ADDR is #defined at compile time, and
        the app/dll gets cygwin-1.7.10+ at runtime
So I'm not sure how much you'd want to rely on the new feature?

>> Basically, this patch means that even if I **DO** configure with
>> --enable-relocation, I won't actually get it.  That's not the right fix.
>>  If I do --enable-relocatable, then by george I ought to get it, slow
>> 5ms operation and all.
> 
> No, you misunderstand it. I have split the relocatable support into a
> cheap part and an expensive part. The cheap part is for people who
> configure one package with --enable-relocatable, or several packages
> with --enable-relocatable and the same prefix. This will continue to
> work.
> 
> The expensive part is support for people who combine two packages,
> built with different --prefix options. This one is costly, because
> every library has to parse /proc/self/maps.
> 
> On Cygwin, many packages come through Cygwin itself, therefore people
> have no need to repackage and redistribute a library that they have
> not built themselves.

But as far as I can tell, there doesn't appear to be any *non-ugly* way
for me to /really/ enable full relocation support on cygwin.  With the
patch you posted, the only way I can see to get "costly relocation" on
cygwin is to add -DENABLE_COSTLY_RELOCATABLE=1 to $C[PP]FLAGS.  Is that
really what you intended?

> Only on native Windows it is likely that people will redistribute
> libraries that they have not built themselves. That's why I kept the
> expensive part enabled by default only on native Windows.

Well, sure.  I'm not arguing about that.  It's just that the way libintl
is built, relocation is always "turned on" regardless of
--enable-relocatable -- but on cygwin, that's now only kinda sorta true.
 And to REALLY turn it on, on cygwin, I need to do something in addition
to --enable-relocatable.

That seems less than ideal.

--
Chuck