Subject: Re: Relocation patch for cygwin
From: jojelino <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Sat, 24 Sep 2011 05:10:00 +0900
List-Id: <cygwin.cygwin.com>

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