public inbox for cygwin-patches@cygwin.com
 help / color / mirror / Atom feed
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin-patches@cygwin.com
Subject: Re: [PATCH] Improve strace to log most Windows debug events
Date: Wed, 10 Jun 2015 17:23:00 -0000	[thread overview]
Message-ID: <20150610172329.GJ31537@calimero.vinschen.de> (raw)
In-Reply-To: <20150610154400.GI31537@calimero.vinschen.de>

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

On Jun 10 17:44, Corinna Vinschen wrote:
> On Jun 10 16:18, Corinna Vinschen wrote:
> > On Jun 10 16:11, Corinna Vinschen wrote:
> > > Hi Jon,
> > > 
> > > On Jun 10 13:05, Jon TURNEY wrote:
> > > > Not sure if this is wanted, but on a couple of occasions recently I have been
> > > > presented with strace output which contains an exception at an address in an
> > > > unknown module (i.e. not in the cygwin DLL or the main executable), so here is a
> > > > patch which adds some more information, including DLL load addresses, to help
> > > > interpret such straces.
> > > 
> > > That's a nice addition.  Two points, though:
> > > 
> > > - Do we *always* want that output or do we want a way to switch it on
> > >   and off?  If the latter, we can simply add another _STRACE_foo option
> > >   for it.  
> > > 
> > > - The GetFileNameFromHandle function could be much simpler.  Rather than
> > >   opening a mapping object for ev.u.LoadDll.hFile, just use the existing
> > >   mapping object from ev.u.LoadDll.lpBaseOfDll.
> > 
> >     ...with the process handle taken from get_child(ev.dwProcessId).
> 
> And since I'm generally fuzzy and unclear in my first reply:
> 
> Of course, ev.u.LoadDll.lpBaseOfDll is not the mapping *object*, but the
> mapping *address*.  So you neither have to call CreateFileMapping nor
> MapViewOfFile.  Just call GetMappedFileNameW (get_child (ev.dwProcessId),
> ev.u.LoadDll.lpBaseOfDll, ...)

This works for me resulting in Win32 pathnames.  These are only the
affected diff hunks, I omited the rest.  Does that work for you?

Btw., I don't like using MAX_PATH as maximum path length, but I think
DLL paths can't be longer anyway, so that should be ok...


diff --git a/winsup/utils/strace.cc b/winsup/utils/strace.cc
index 73096ab..0661e17 100644
--- a/winsup/utils/strace.cc
+++ b/winsup/utils/strace.cc
@@ -54,6 +54,8 @@ static BOOL close_handle (HANDLE h, DWORD ok);
 
 #define CloseHandle(h) close_handle(h, 0)
 
+static void *drive_map;
+
 struct child_list
 {
   DWORD id;
@@ -637,6 +639,30 @@ handle_output_debug_string (DWORD id, LPVOID p, unsigned mask, FILE *ofile)
     fflush (ofile);
 }
 
+static BOOL
+GetFileNameFromHandle(HANDLE hFile, WCHAR pszFilename[MAX_PATH+1])
+{
+  BOOL result = FALSE;
+  ULONG len = 0;
+  OBJECT_NAME_INFORMATION *ntfn = (OBJECT_NAME_INFORMATION *) alloca (65536);
+  NTSTATUS status = NtQueryObject (hFile, ObjectNameInformation,
+				   ntfn, 65536, &len);
+  if (NT_SUCCESS (status))
+    {
+      PWCHAR win32path = ntfn->Name.Buffer;
+      win32path[ntfn->Name.Length / sizeof (WCHAR)] = L'\0';
+
+      /* NtQueryObject returns a native NT path.  (Try to) convert to Win32. */
+      if (drive_map)
+	win32path = (PWCHAR) cygwin_internal (CW_MAP_DRIVE_MAP, drive_map,
+					      win32path);
+      pszFilename[0] = L'\0';
+      wcsncat (pszFilename, win32path, MAX_PATH);
+      result = TRUE;
+    }
+  return result;
+}
+
 static DWORD
 proc_child (unsigned mask, FILE *ofile, pid_t pid)
 {
@@ -1090,7 +1143,13 @@ character #%d.\n", optarg, (int) (endptr - optarg), endptr);
   if (toggle)
     dotoggle (pid);
   else
-    ExitProcess (dostrace (mask, ofile, pid, argv + optind));
+    {
+      drive_map = (void *) cygwin_internal (CW_ALLOC_DRIVE_MAP);
+      DWORD ret = dostrace (mask, ofile, pid, argv + optind);
+      if (drive_map)
+	cygwin_internal (CW_FREE_DRIVE_MAP, drive_map);
+      ExitProcess (ret);
+    }
   return 0;
 }
 

Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2015-06-10 17:23 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-10 12:05 Jon TURNEY
2015-06-10 14:11 ` Corinna Vinschen
2015-06-10 14:18   ` Corinna Vinschen
2015-06-10 15:44     ` Corinna Vinschen
2015-06-10 17:23       ` Corinna Vinschen [this message]
2015-06-10 18:47         ` Jon TURNEY
2015-06-10 18:44 ` Jon TURNEY

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150610172329.GJ31537@calimero.vinschen.de \
    --to=corinna-cygwin@cygwin.com \
    --cc=cygwin-patches@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).