This is the mail archive of the cygwin 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: Relocation patch for cygwin


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.

Attachment: gmon.id.exe.1656.out.txt
Description: Text document

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

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