Add cygwin_internal CW_GET_MODULE_PATH_FOR_ADDR

Add cygwin_internal CW_GET_MODULE_PATH_FOR_ADDR

[Charles Wilson]

[-- Attachment #1: Type: text/plain, Size: 1346 bytes --]

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



[-- Attachment #2: cygwin-internal-new-fnc.patch --]
[-- Type: application/x-patch, Size: 5810 bytes --]

[-- Attachment #3: test-get-module-path-for-addr.cc --]
[-- Type: text/plain, Size: 877 bytes --]

#include <iostream>
#include <iomanip>
#include <sstream>
#include <fstream>
#include <string>
#include <unistd.h>
#include <sys/cygwin.h>
#include <limits.h>

#define NO_MINMAX
#include <windows.h>

int main(int argc, char* argv[])
{
  int pid = getpid ();
  std::ostringstream ostr;
  ostr << "/proc/" << pid << "/maps";
  std::ifstream ifs(ostr.str().c_str());
  std::cout << ifs.rdbuf() << std::endl;

  uintptr_t addr;
  WCHAR wbuf[PATH_MAX];
  char  nbuf[4*PATH_MAX];

  while (std::cin)
  {
    std::cin >> std::hex >> addr;
    if (std::cin)
    {
      wbuf[0] = L'\0';
      int rval = cygwin_internal(CW_GET_MODULE_PATH_FOR_ADDR,
        addr, wbuf, PATH_MAX);
      wcstombs (nbuf, wbuf, 4*PATH_MAX);
      std::cout << "0x" << std::hex << std::setw(8) << std::setfill('0')
	<< addr << " (" << std::dec << rval << ") " << nbuf << std::endl;
    }
  }
  return 0;
}

Re: Add cygwin_internal CW_GET_MODULE_PATH_FOR_ADDR

[Corinna Vinschen]

On Oct 13 10:20, Charles Wilson wrote:
> >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?

The first and foremost question is, what is the relocation support
in libintl trying to accomplish?  Why does a internationalization
library has to know the path of a module based on an address?
Is that a functionality required on other POSIX systems?

Can we discuss this on cygwin-developers first, please?  So far I doubt
that this makes any sense on Cygwin.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat