Relocation patch for cygwin
jojelino
jojelino@gmail.com
Sun Sep 25 09:03:00 GMT 2011
On 2011-01-29 AM 3:04, Charles Wilson wrote:
> On the cygwin list, Corinna Vinschen, one of the main cygwin developers
> and project lead, noticed a problem with libiconv's behavior on cygwin
> 1.7.x (which I'll follow up on the appropriate list, in a few days).
>
> However, while she was investigating it, she ran across some very
> obsolete code in the relocation support employed by libintl. In keeping
> with cygwin's mantra of "more like unix, less like windows", she
> suggested the following changes. These basically make cygwin's
> relocation support use the linux machanisms (/proc/self/maps,
> /proc/self/exe) rather than relying on win32 mechanisms like
> GetModuleFileName, DllMain(), and the like.
>
> An added benefit of using the linux mechanisms on cygwin, is that the
> paths are therefore already in cygwin/unix format, and there is no need
> to convert them from/to win32 format.
>
> Speaking of which, the old conversion code used functions which (a) are
> now deprecated, and (b) do not support paths longer than 254 characters.
>
> As modified by this patch, extremely long path names are now supported,
> as well as those containing non-ascii characters.
>
> The only remaining vestige of win32ness in the patched code is that, for
> characters in the A-Za-z range, filename comparison is performed
> case-insensitively. (There might be an issue here if the filename(s)
> contain UTF-8 encoded multibyte characters, leading to false
> equivalence. But the odds of that seem pretty low...and the effects if
> it DID happen pretty minor, it appears to me. The alternative is to use
> some locale-sensitive case conversion function, and then compare the
> results...but that belongs in a different patch IMO.)
>
> Concerns about backwards compatibility: the mechanisms exploited by the
> "linux" code have been supported by cygwin since March 1 2005, with
> cygwin-1.5.13. That's almost six years. Plus, the cygwin project no
> longer supports ANY cygwin older than 1.7.x -- and 1.7.1 dates back more
> than a year. So, while the "new" code won't work on EXTREMELY old
> cygwin, I think it's quite reasonable to require>= 1.5.13. The only
> likely complaints might come from the MSYS project, since they are based
> on cygwin-1.3.4, but...since they deliberately operate in a closed
> garden [*] they -- by which I mean "me" [**] -- will just have to deal
> with it.
>
> [*] They choose NOT to even allow config.guess to recognize their
> triple, and don't ship their '#ifdef __MSYS__' patches upstream for ANY
> projects. They are an "unofficial" port in every sense of the word.
>
> [**] I am the maintainer of libiconv and gettext on MSYS, so...I'll just
> deal with any problems this change might create on that platform. No
> need to force code on the "real" cygwin to use outdated, and deprecated,
> interfaces just to keep msys happy.
>
>
>
> 2011-01-27 Corinna Vinschen<...>
> Charles Wilson<...>
>
> On Cygwin, use unix mechanisms instead of win32
> * progreloc.c: Prefer linux code throughout, rather than
> win32 implementations.
> (find_executable): Eliminate Cygwin path conversion logic
> from WIN32 code, as Cygwin now uses linux implementation.
> * relocatable.c: Prefer linux code throughout, rather than
> win32 implementations.
> (DllMain): Eliminate Cygwin path conversion logic from WIN32
> code, as Cygwin now uses linux implementation and does not
> require a custom DllMain.
> (find_shared_library_fullname): Use linux implementation for
> Cygwin.
> (get_shared_library_fullname): Allow on-demand initialization
> for Cygwin, as DllMain is no longer used to pre-initialize.
>
>
> --
> Chuck
It fixed the relocation problem. but led performance issue :(
$ time id > /dev/null
real 0m0.141s
user 0m0.000s
sys 0m0.000s
The attached is report gprof produced when invoked *id* . as you can
see, format_process_maps consumes 70% of the lifetime(0.5s with
profiling overhead). this is reproducible whenever we do
open('/proc/self/maps').
the problem is, the cost is too expensive. gnulib should care about
cygwin do sacrifice performance for compatibility.
As a workaround, how about rebuild libintl without capacity of relocatable?
because in cygwin libintl is expected to place in /bin so there's no use
of relocatable.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gmon.id.exe.1656.out.txt
URL: <http://cygwin.com/pipermail/cygwin/attachments/20110925/62761169/attachment.txt>
-------------- next part --------------
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin
mailing list