Add cygwin_internal CW_GET_MODULE_PATH_FOR_ADDR

Charles Wilson cygwin@cwilson.fastmail.fm
Thu Oct 13 14:20:00 GMT 2011


>From discussions with Bruno Haible about the slowness of full relocation
support in libintl and libiconv, he said:

>   - The Cygwin API only allows me to get _all_ file names behind all
>     addresses across the entire current process, and this is slow.

(talking about parsing /proc/self/maps)

>   - It would be useful to have a Cygwin API that gives me the file
>     file name behind one particular address in the current process.
>     This should not be that slow.

This patch is a proof of concept for the latter.  Naturally, it needs
additional work -- updating version.h, real changelog entries,
documentation somewhere, etc.  But...is it worth the effort?  Is
something like this likely to be accepted?

I've also attached a test program.  To compile it (using g++), you need
to ensure that the updated sys/cygwin.h is in the search path.  It
prints the contents of /proc/self/maps, and then you can type any (hex)
memory address and it should report the func's return value, and the
correct path to the associated module.  CTRL-D to exit.

61000020
0x61000020 (0) /usr/bin/cygwin1.dll
00020000
0x00020000 (1)

The call signature is:

	unsigned long
	cygwin_internal (CW_GET_MODULE_PATH_FOR_ADDR,
                         uintptr_t addr,
                         PWCHAR    buf,
                         size_t    buflen);

--
Chuck


-------------- next part --------------
A non-text attachment was scrubbed...
Name: cygwin-internal-new-fnc.patch
Type: application/x-patch
Size: 5810 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin-patches/attachments/20111013/136ef371/attachment.bin>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test-get-module-path-for-addr.cc
URL: <http://cygwin.com/pipermail/cygwin-patches/attachments/20111013/136ef371/attachment.cc>


More information about the Cygwin-patches mailing list