Re: Add cygwin_internal CW_GET_MODULE_PATH_FOR_ADDR

[Reini Urban <rurban at x-ray dot at>]

On Sat, Oct 15, 2011 at 3:51 AM, Corinna Vinschen  wrote:
> On Oct 15 01:00, Charles Wilson wrote:
>> On 10/14/2011 5:18 AM, Corinna Vinschen wrote:
>> >I had a look into gettext-runtime/intl/setlocale.c and it drives me
>> >nuts. ?I told Bruno back in January already not to use Windowisms on
>> >Cygwin.
>>
>> Well, (a) it will take time to back out the existing windowsism
>> (most of what you see dates from pre-cygwin-1.7), and (b) the cygwin
>> implementation is not nearly as ugly as you might think, if you look
>> at what is inactivated on __CYGWIN__. ?I've attached the
>> pre-processed version below (with all the header stuff deleted). ?It
>> does /some/ extra stuff, but not all that ickiness that native win32
>> requires.
...
>> However, I had already come to the conclusion that simply applying
>> Bruno's "cheap vs. expensive" fix from CVS will do, for now. ?This
>> doesn't require any new cygwin APIs. ?The new API is only an attempt
>> to speed up "expensive" relocation (which cygwin's official packages
>> will never need to do) while staying at least somewhat
>> unixy/cygwiny, rather than calling the w32api.
>
> Cool! ?That's the solution then.
>
>> >Well, if that's really necessary, then, for heaven's sake, let them use
>> >the code in gettext-runtime/gnulib-lib/relocatable.c, but with a good
>> >tweak:
>> >
>> >- Call GetModuleFileNameW instead of GetModuleFileName.
>>
>> After we told Bruno to not use any windowsisms? ?Sure, it's a lot
>> simpler -- but it violates our recommendations for cygwin clients.
>
> I don't think it makes sense to add a cygwin_internal call for this
> functionality. ?The idea was to use the same code as Linux here and to
> avoid any Cygwinism. ?If using /proc/$PID/maps is not enough, then
> that's not possible. ?So in turn, there's no practical difference between
>
> ?#ifdef __CYGWIN__
> ? ?cygwin_internal (CW_GET_MODULE_PATH_FOR_ADDR,
> ? ? ? ? ? ? ? ? ? ? addr, buf, sizeof (buf))
> ? ?shared_library_fullname = strdup (buf);
> ?#endif
>
> and
>
> ?#ifdef __CYGWIN__
> ? ?GetModuleFileNameW (module_handle, buf, sizeof (buf)))
> ? ?shared_library_fullname = (char *) cygwin_create_path (CCP_WIN_W_TO_POSIX,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? buf);
> ?#endif
>
> In both cases you have to use a Cygwinism and you have to guard the
> code using #ifdef __CYGWIN__.

Actually mingw needs GetModuleFileNameW for relocatable support also.
With cygwin you just have to add the path conversion.
I'm fully with Corinna here.
Better use a simple and well-known API than inventing a new one.
In Perl we are also adding relocation support right now. (5.16)

Speeding up /proc/self/maps could be worthwhile but certainly not easy.
And parsing this list it is also useless time spended, when we can use
native GetModuleFileNameW instead.

>> But making "expensive" relocation less expensive doesn't have to be
>> solved this very minute.
>
> Actually, since we have two types of relocation anyway, cheap and
> expensive, why isn't it enough to have an expensive relocation using the
> maps file? ?Somehow I missed the numbers. ?How slow is accessing the
> maps file in comparison?

-- 
Reini Urban
http://cpanel.net/ ? http://www.perl-compiler.org/