Relocation patch for cygwin

Ryan Johnson
Sun Sep 25 14:09:00 GMT 2011

On 23/09/2011 4:10 PM, 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.
> 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.
Hmm. I'm not up to speed on what the relocation issue is/was, but from 
what I've seen of the proc/*/maps code path, they are expensive enough I 
would think twice about putting it on the critical path. That said, the 
amount of time consumed makes me wonder if the file is being opened/read 
multiple times, resulting in O(n^2) work overall.


Problem reports:
Unsubscribe info:

More information about the Cygwin mailing list