X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-0.3 required=5.0 tests=AWL,BAYES_50,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_NONE,UNPARSEABLE_RELAY X-Spam-Check-By: sourceware.org X-Yahoo-SMTP: jenXL62swBAWhMTL3wnej93oaS0ClBQOAKs8jbEbx_o- Date: Fri, 23 Sep 2011 23:16:42 -0400 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: Relocation patch for cygwin Message-ID: <20110924031642.GA25393@ednor.casa.cgf.cx> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <4D430530 DOT 7050401 AT cwilson DOT fastmail DOT fm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com On Sat, Sep 24, 2011 at 05:10:00AM +0900, jojelino wrote: >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. >Flat profile: Please don't send this type of stuff here. You've just spammed hundreds of people with many kilobytes data that very few people care about. cgf -- 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