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