This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Add cygwin_internal CW_GET_MODULE_PATH_FOR_ADDR


On 10/15/2011 4:51 AM, Corinna Vinschen wrote:
On Oct 15 01:00, Charles Wilson wrote:
>> [stuff]
Sorry, I meant localename.c.  Almost everything for Win32 is done
for Cygwin as well.  Plus ignoring C.UTF-8 explicitly just on Cygwin.
That's cruel.

My working patch #ifdefs-out removes almost all of the code in localename.c.


No.  Now that cygintl-8.dll has been published with an added
interface (libintl_setlocale) I can't remove that new symbol without
breaking any apps compiled in the meantime.

libintl_setlocale is only defined if ENABLE_RELOCATABLE is defined? That's not immediately visble from ther sources.

That's what Bruno said, and I had no reason to doubt him and verify it in the sources. I'll check later, but no time right now.


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.

Yep. Seems to solve the complaint. Now if I can just figure out where the handful of new testsuite failures are coming from -- could be they are explicitly testing for the functionality I removed. Need to investigate.


Also, need to do a private build with the two different forms of relocation, and verify functionality but I can do that after uploading the official versions.

After we told Bruno to not use any windowsisms?  Sure, it's a lot
simpler -- but it violates our recommendations for cygwin clients.

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__.

Ack.


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?

Well, at the time I was thinking that if "expensive" could be made cheap *enough*, we could remove the distinction again. The issue I have with Bruno's solution is that we now have three states, in the relocation code -- but only for cygwin. And the states are controlled by two different mechanisms:
--disable-relocation + -UENABLE_COSTLY_RELOCATABLE (default) [*]
--enable-relocation + -UENABLE_COSTLY_RELOCATABLE
--enable-relocation + -DENABLE_COSTLY_RELOCATABLE


[*] subverted in libintl's Makefile with its -DENABLE_RELOCATABLE

That's just ugly.

Somehow I missed the numbers.  How slow is accessing the
maps file in comparison?

10-20x slower than linux -- 3 5o 5 ms per call, vs. 0.3 ms for linux. (Those are Bruno's timing investigation numbers).


I don't think it makes sense to add a cygwin_internal call for this
functionality.

OK. We can take this back to the main cygwin list now, then.


--
Chuck


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]