[RFA] win32-nat.c: Add dll names if debugevents is on

[RFA] win32-nat.c: Add dll names if debugevents is on

[Pierre Muller]

 This is a very simple patch that add
a line giving the name of the newly loaded 
or unloaded dll, 
when 'set debugevents on' is used.
  It does not change the
default behavior of cygwin/mingw32 gdb
as debugevents is off by default.

 I always found it frustrating to get the
events LOAD_DLL_DEBUG_EVENT and
UNLOAD_DLL_DEBUG_EVENT without getting the name of the 
dll.


This is the new behavior:

$ gdb-dllnames.exe ./run.exe
GNU gdb (GDB) 6.8.50.20080611-cvs
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-cygwin".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
(gdb) set debugevents on
(gdb) r
Starting program:
/usr/local/src/gdbcvs/build-bare/gdb/testsuite/gdb.base/run.ex
e
gdb: win32_init_thread_list
gdb: kernel event for pid=4068 tid=2992 code=CREATE_PROCESS_DEBUG_EVENT)
[New thread 4068.0xbb0]
ContinueDebugEvent (cpid=4068, ctid=2992, DBG_CONTINUE);
gdb: kernel event for pid=4068 tid=2992 code=LOAD_DLL_DEBUG_EVENT)
Loading dll "ntdll.dll".
ContinueDebugEvent (cpid=4068, ctid=2992, DBG_CONTINUE);
gdb: kernel event for pid=4068 tid=2992 code=LOAD_DLL_DEBUG_EVENT)
Loading dll "D:\WINDOWS\system32\kernel32.dll".
ContinueDebugEvent (cpid=4068, ctid=2992, DBG_CONTINUE);
gdb: kernel event for pid=4068 tid=2992 code=LOAD_DLL_DEBUG_EVENT)
Loading dll "E:\cygwin\home\Pierre\bin\cygwin1.dll".
ContinueDebugEvent (cpid=4068, ctid=2992, DBG_CONTINUE);
gdb: kernel event for pid=4068 tid=2992 code=LOAD_DLL_DEBUG_EVENT)
Loading dll "D:\WINDOWS\system32\ADVAPI32.DLL".
ContinueDebugEvent (cpid=4068, ctid=2992, DBG_CONTINUE);
gdb: kernel event for pid=4068 tid=2992 code=LOAD_DLL_DEBUG_EVENT)
Loading dll "D:\WINDOWS\system32\RPCRT4.dll".
ContinueDebugEvent (cpid=4068, ctid=2992, DBG_CONTINUE);
gdb: kernel event for pid=4068 tid=2992 code=LOAD_DLL_DEBUG_EVENT)
Loading dll "D:\WINDOWS\system32\Secur32.dll".
ContinueDebugEvent (cpid=4068, ctid=2992, DBG_CONTINUE);
gdb: kernel event for pid=4068 tid=2992 code=EXCEPTION_DEBUG_EVENT)
ContinueDebugEvent (cpid=4068, ctid=2992, DBG_CONTINUE);
gdb: kernel event for pid=4068 tid=6f8 code=CREATE_THREAD_DEBUG_EVENT)
[New thread 4068.0x6f8]
ContinueDebugEvent (cpid=4068, ctid=1784, DBG_CONTINUE);
gdb: kernel event for pid=4068 tid=2992 code=OUTPUT_DEBUG_STRING_EVENT)
ContinueDebugEvent (cpid=4068, ctid=2992, DBG_CONTINUE);
gdb: kernel event for pid=4068 tid=2992 code=OUTPUT_DEBUG_STRING_EVENT)
ContinueDebugEvent (cpid=4068, ctid=2992, DBG_CONTINUE);
gdb: kernel event for pid=4068 tid=2992 code=LOAD_DLL_DEBUG_EVENT)
Loading dll "D:\WINDOWS\system32\user32.dll".
ContinueDebugEvent (cpid=4068, ctid=2992, DBG_CONTINUE);
gdb: kernel event for pid=4068 tid=2992 code=LOAD_DLL_DEBUG_EVENT)
Loading dll "D:\WINDOWS\system32\GDI32.dll".
ContinueDebugEvent (cpid=4068, ctid=2992, DBG_CONTINUE);
gdb: kernel event for pid=4068 tid=2992 code=LOAD_DLL_DEBUG_EVENT)
Loading dll "D:\WINDOWS\system32\IMM32.DLL".
ContinueDebugEvent (cpid=4068, ctid=2992, DBG_CONTINUE);
usage:  factorial <number>
gdb: kernel event for pid=4068 tid=1784 code=EXIT_THREAD_DEBUG_EVENT)
ContinueDebugEvent (cpid=4068, ctid=1784, DBG_CONTINUE);
gdb: kernel event for pid=4068 tid=2992 code=LOAD_DLL_DEBUG_EVENT)
Loading dll "D:\WINDOWS\system32\psapi.dll".
ContinueDebugEvent (cpid=4068, ctid=2992, DBG_CONTINUE);
gdb: kernel event for pid=4068 tid=2992 code=EXIT_PROCESS_DEBUG_EVENT)

Program exited with code 01.
ContinueDebugEvent (cpid=4068, ctid=2992, DBG_CONTINUE);
gdb: win32_close, inferior_ptid=2992
(gdb) q

Compared to the current behavior:

Pierre@d620-muller ~/gdbcvs/build-bare/gdb/testsuite/gdb.base
$ ../../gdb ./run.exe
GNU gdb (GDB) 6.8.50.20080611-cvs
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-cygwin".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
(gdb) set debugevents on
(gdb) r
Starting program:
/usr/local/src/gdbcvs/build-bare/gdb/testsuite/gdb.base/run.ex
e
gdb: win32_init_thread_list
gdb: kernel event for pid=260 tid=2540 code=CREATE_PROCESS_DEBUG_EVENT)
[New thread 260.0x9ec]
ContinueDebugEvent (cpid=260, ctid=2540, DBG_CONTINUE);
gdb: kernel event for pid=260 tid=2540 code=LOAD_DLL_DEBUG_EVENT)
ContinueDebugEvent (cpid=260, ctid=2540, DBG_CONTINUE);
gdb: kernel event for pid=260 tid=2540 code=LOAD_DLL_DEBUG_EVENT)
ContinueDebugEvent (cpid=260, ctid=2540, DBG_CONTINUE);
gdb: kernel event for pid=260 tid=2540 code=LOAD_DLL_DEBUG_EVENT)
ContinueDebugEvent (cpid=260, ctid=2540, DBG_CONTINUE);
gdb: kernel event for pid=260 tid=2540 code=LOAD_DLL_DEBUG_EVENT)
ContinueDebugEvent (cpid=260, ctid=2540, DBG_CONTINUE);
gdb: kernel event for pid=260 tid=2540 code=LOAD_DLL_DEBUG_EVENT)
ContinueDebugEvent (cpid=260, ctid=2540, DBG_CONTINUE);
gdb: kernel event for pid=260 tid=2540 code=LOAD_DLL_DEBUG_EVENT)
ContinueDebugEvent (cpid=260, ctid=2540, DBG_CONTINUE);
gdb: kernel event for pid=260 tid=2540 code=EXCEPTION_DEBUG_EVENT)
ContinueDebugEvent (cpid=260, ctid=2540, DBG_CONTINUE);
gdb: kernel event for pid=260 tid=ec8 code=CREATE_THREAD_DEBUG_EVENT)
[New thread 260.0xec8]
ContinueDebugEvent (cpid=260, ctid=3784, DBG_CONTINUE);
gdb: kernel event for pid=260 tid=2540 code=OUTPUT_DEBUG_STRING_EVENT)
ContinueDebugEvent (cpid=260, ctid=2540, DBG_CONTINUE);
gdb: kernel event for pid=260 tid=2540 code=OUTPUT_DEBUG_STRING_EVENT)
ContinueDebugEvent (cpid=260, ctid=2540, DBG_CONTINUE);
gdb: kernel event for pid=260 tid=2540 code=LOAD_DLL_DEBUG_EVENT)
ContinueDebugEvent (cpid=260, ctid=2540, DBG_CONTINUE);
gdb: kernel event for pid=260 tid=2540 code=LOAD_DLL_DEBUG_EVENT)
ContinueDebugEvent (cpid=260, ctid=2540, DBG_CONTINUE);
gdb: kernel event for pid=260 tid=2540 code=LOAD_DLL_DEBUG_EVENT)
ContinueDebugEvent (cpid=260, ctid=2540, DBG_CONTINUE);
usage:  factorial <number>
gdb: kernel event for pid=260 tid=3784 code=EXIT_THREAD_DEBUG_EVENT)
ContinueDebugEvent (cpid=260, ctid=3784, DBG_CONTINUE);
gdb: kernel event for pid=260 tid=2540 code=LOAD_DLL_DEBUG_EVENT)
ContinueDebugEvent (cpid=260, ctid=2540, DBG_CONTINUE);
gdb: kernel event for pid=260 tid=2540 code=EXIT_PROCESS_DEBUG_EVENT)

Program exited with code 01.
ContinueDebugEvent (cpid=260, ctid=2540, DBG_CONTINUE);
gdb: win32_close, inferior_ptid=2540
(gdb) q

Is this OK to commit?


Pierre Muller
Pascal language support maintainer for GDB




ChangeLog entry:

2008-12-13  Pierre Muller  <muller@ics.u-strasbg.fr>

	* win32-nat.c (handle_load_dll): Give dll name
	if debug_events is on.
	(handle_unload_dll): Likewise.



$ cvs diff -up gdb/win32-nat.c
Index: gdb/win32-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/win32-nat.c,v
retrieving revision 1.152
diff -u -p -r1.152 win32-nat.c
--- gdb/win32-nat.c     20 May 2008 18:36:36 -0000      1.152
+++ gdb/win32-nat.c     13 Jun 2008 11:27:18 -0000
@@ -744,6 +744,7 @@ handle_load_dll (void *dummy)
   if (!dll_name)
     return 1;

+  DEBUG_EVENTS (("gdb: Loading dll \"%s\".\n",dll_name));
   solib_end->next = win32_make_so (dll_name, (DWORD) event->lpBaseOfDll);
   solib_end = solib_end->next;

@@ -771,6 +772,9 @@ handle_unload_dll (void *dummy)
        so->next = sodel->next;
        if (!so->next)
          solib_end = so;
+       if (sodel->so_original_name)
+         DEBUG_EVENTS (("gdb: removing dll \"%s\".\n",
+                        sodel->so_original_name));
        win32_free_so (sodel);
        solib_add (NULL, 0, NULL, auto_solib_add);
        return 1;

Re: [RFA] win32-nat.c: Add dll names if debugevents is on

[Pedro Alves]

Thanks, I've wanted this before too.

A Friday 13 June 2008 14:17:11, Pierre Muller wrote:

> $ cvs diff -up gdb/win32-nat.c
> Index: gdb/win32-nat.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/win32-nat.c,v
> retrieving revision 1.152
> diff -u -p -r1.152 win32-nat.c
> --- gdb/win32-nat.c     20 May 2008 18:36:36 -0000      1.152
> +++ gdb/win32-nat.c     13 Jun 2008 11:27:18 -0000
> @@ -744,6 +744,7 @@ handle_load_dll (void *dummy)
>    if (!dll_name)
>      return 1;
>
> +  DEBUG_EVENTS (("gdb: Loading dll \"%s\".\n",dll_name));
>    solib_end->next = win32_make_so (dll_name, (DWORD) event->lpBaseOfDll);

While you're at it, would it be useful to also include the dll
load base in the output?

>    solib_end = solib_end->next;
>
> @@ -771,6 +772,9 @@ handle_unload_dll (void *dummy)
>         so->next = sodel->next;
>         if (!so->next)
>           solib_end = so;
> +       if (sodel->so_original_name)
> +         DEBUG_EVENTS (("gdb: removing dll \"%s\".\n",

Small nit, wouldn't "gdb: Unloading dll" be clearer (and mirror
the other message) ?  And perhaps output "<unknown name>", if
there's no so_original_name to print?  Can that happen?  I
can't remember off-hand.

-- 
Pedro Alves

RE: [RFA] win32-nat.c: Add dll names if debugevents is on

[Pierre Muller]

Thanks for the comments

>-----Message d'origine-----
>De : Pedro Alves [mailto:pedro_alves@portugalmail.pt] 
>Envoyé : Friday, June 13, 2008 4:32 PM
>À : gdb-patches@sourceware.org
>Cc : Pierre Muller
>Objet : Re: [RFA] win32-nat.c: Add dll names if debugevents is on
>
>Thanks, I've wanted this before too.
>
>A Friday 13 June 2008 14:17:11, Pierre Muller wrote:
>
>>
>> +  DEBUG_EVENTS (("gdb: Loading dll \"%s\".\n",dll_name));
>>    solib_end->next = win32_make_so (dll_name, (DWORD)
event->lpBaseOfDll);
>
>While you're at it, would it be useful to also include the dll
>load base in the output?

  It’s a good idea, that I implemented easily, see below.
I choose to use the solib struct to be closer to 'info dll' output.
The only caveat is that it doesn't match the values given by 'info dll'
later
because of the 0x1000 offset added to the start of each Dll,
should I add  this 0x1000?

>> +       if (sodel->so_original_name)
>> +         DEBUG_EVENTS (("gdb: removing dll \"%s\".\n",
>
>Small nit, wouldn't "gdb: Unloading dll" be clearer (and mirror
>the other message) ?  And perhaps output "<unknown name>", if
>there's no so_original_name to print?  Can that happen?  I
>can't remember off-hand.

  It seems like so_original_name is never empty,
because if the dll name is not found, the dll is not recorded at all.
  And I finally realized that my code was wrong because
so_original_name and so_name are char array, not pointers...
I nevertheless check both so_name and so_original_name
in that order, without knowing if one can be set and 
not the other...


Here is an updated patch:


ChangeLog entry:

2008-12-13  Pierre Muller  <muller@ics.u-strasbg.fr>

	* win32-nat.c (handle_load_dll): Give dll name and load address
	if debug_events is on.
	(handle_unload_dll): Likewise.


$ cat dllnames.patch
Index: gdb/win32-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/win32-nat.c,v
retrieving revision 1.152
diff -u -p -r1.152 win32-nat.c
--- gdb/win32-nat.c     20 May 2008 18:36:36 -0000      1.152
+++ gdb/win32-nat.c     13 Jun 2008 21:51:19 -0000
@@ -747,6 +747,9 @@ handle_load_dll (void *dummy)
   solib_end->next = win32_make_so (dll_name, (DWORD) event->lpBaseOfDll);
   solib_end = solib_end->next;

+  DEBUG_EVENTS (("gdb: Loading dll \"%s\" at 0x%lx.\n", solib_end->so_name,
+                (DWORD) solib_end->lm_info->load_addr));
+
   return 1;
 }

@@ -771,6 +774,18 @@ handle_unload_dll (void *dummy)
        so->next = sodel->next;
        if (!so->next)
          solib_end = so;
+       if (sodel->so_name != "\0")
+         {
+           DEBUG_EVENTS (("gdb: Unloading dll \"%s\".\n",
+                          (char *) &(sodel->so_name)));
+         }
+       else if (sodel->so_original_name != "\0")
+         {
+           DEBUG_EVENTS (("gdb: Unloading dll \"%s\".\n",
+                          (char *) &(sodel->so_original_name)));
+         }
+       else
+         DEBUG_EVENTS (("gdb: Unloading <unknown name> dll.\n"));
        win32_free_so (sodel);
        solib_add (NULL, 0, NULL, auto_solib_add);
        return 1;

Re: [RFA] win32-nat.c: Add dll names if debugevents is on

[Pedro Alves]

A Friday 13 June 2008 23:00:40, Pierre Muller wrote:
> Thanks for the comments

> >While you're at it, would it be useful to also include the dll
> >load base in the output?
>
>   It’s a good idea, that I implemented easily, see below.
> I choose to use the solib struct to be closer to 'info dll' output.
> The only caveat is that it doesn't match the values given by 'info dll'
> later
> because of the 0x1000 offset added to the start of each Dll,
> should I add  this 0x1000?

I've no strong opinion, handle_unload_dll already erros without ...

>   It seems like so_original_name is never empty,
> because if the dll name is not found, the dll is not recorded at all.
>   And I finally realized that my code was wrong because
> so_original_name and so_name are char array, not pointers...
> I nevertheless check both so_name and so_original_name
> in that order, without knowing if one can be set and
> not the other...

See win32_make_so.  so_name is always built from so_original_name.

>
> Here is an updated patch:
>

This patch surely doesn't work.

> @@ -771,6 +774,18 @@ handle_unload_dll (void *dummy)
>         so->next = sodel->next;
>         if (!so->next)
>           solib_end = so;
> +       if (sodel->so_name != "\0")
> +         {
> +           DEBUG_EVENTS (("gdb: Unloading dll \"%s\".\n",
> +                          (char *) &(sodel->so_name)));
> +         }
> +       else if (sodel->so_original_name != "\0")
> +         {
> +           DEBUG_EVENTS (("gdb: Unloading dll \"%s\".\n",
> +                          (char *) &(sodel->so_original_name)));
> +         }
> +       else
> +         DEBUG_EVENTS (("gdb: Unloading <unknown name> dll.\n"));

<side note>

  Beware that DEBUG_EVENTS is not safe to reguarding dangling else's...

  #define DEBUG_EVENTS(x)	if (debug_events)	printf_unfiltered x

  That should be fixed to something like:

  #define DEBUG_EVENTS(x) \
   do { if (debug_events) printf_unfiltered x ; } while (0)

  Or better, to output to fprintf_unfiltered (gdb_stdlog, ...

  Otherwise, extra braces are indeed required.

</side note>

> +       if (sodel->so_name != "\0")

Anyway, these comparision aren't doing what you think they are.
You are still comparing addresses.  To check for empty string, use
something like:

     if (*sodel->so_name == '\0')


> +           DEBUG_EVENTS (("gdb: Unloading dll \"%s\".\n",
> +                          (char *) &(sodel->so_name)));

And should print a char array like you were doing before:
 DEBUG_EVENTS (("gdb: Unloading dll \"%s\".\n", sodel->so_name));

But, if so_name is built from so_original_name, and you're printing
just so_name in the load event, why extra that churn in the unload event?  
Just:

+         DEBUG_EVENTS (("gdb: Unloading dll \"%s\".\n",
+                        sodel->so_name));

Would be enough, I guess.

-- 
Pedro Alves

[RFA-v3] win32-nat.c: Add dll names if debugevents is on

[Pierre Muller]

 Thanks Pedro,

  this is my trouble as I am mainly a pascal programmer: 
I am always lost in implicit typecast/conversion rules :(

  The patch is thus even simpler:

ChangeLog entry:

2008-12-14  Pierre Muller  <muller@ics.u-strasbg.fr>

	* win32-nat.c (handle_load_dll): Give dll name and load address
	if debug_events is on.
	(handle_unload_dll): Likewise.


$ cvs diff -up gdb/win32-nat.c
Index: gdb/win32-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/win32-nat.c,v
retrieving revision 1.152
diff -u -p -r1.152 win32-nat.c
--- gdb/win32-nat.c     20 May 2008 18:36:36 -0000      1.152
+++ gdb/win32-nat.c     13 Jun 2008 23:02:29 -0000
@@ -747,6 +747,9 @@ handle_load_dll (void *dummy)
   solib_end->next = win32_make_so (dll_name, (DWORD) event->lpBaseOfDll);
   solib_end = solib_end->next;

+  DEBUG_EVENTS (("gdb: Loading dll \"%s\" at 0x%lx.\n", solib_end->so_name,
+                (DWORD) solib_end->lm_info->load_addr));
+
   return 1;
 }

@@ -771,6 +774,8 @@ handle_unload_dll (void *dummy)
        so->next = sodel->next;
        if (!so->next)
          solib_end = so;
+       DEBUG_EVENTS (("gdb: Unloading dll \"%s\".\n", sodel->so_name));
+
        win32_free_so (sodel);
        solib_add (NULL, 0, NULL, auto_solib_add);
        return 1;

Re: [RFA-v3] win32-nat.c: Add dll names if debugevents is on

[Christopher Faylor]

On Sat, Jun 14, 2008 at 01:07:12AM +0200, Pierre Muller wrote:
> Thanks Pedro,
>
>  this is my trouble as I am mainly a pascal programmer: 
>I am always lost in implicit typecast/conversion rules :(
>
>  The patch is thus even simpler:

I guess my basic question here is why is this needed at all?  Does
the non-windows version of gdb have something similar?  If so, this
should be patterned after that.  If not, why is Windows special?

cgf

Re: [RFA-v3] win32-nat.c: Add dll names if debugevents is on

[Pedro Alves]

A Sunday 15 June 2008 23:53:30, Christopher Faylor wrote:

> I guess my basic question here is why is this needed at all?  Does
> the non-windows version of gdb have something similar?  If so, this
> should be patterned after that.  If not, why is Windows special?

Well, with set "set verbose 1" you can see dll names being
read in already, but you also get a lot more.  This is just a
couple of lines to add some debug output.  Note that it
can't be much patterned (without some extra hair) other than
printing the so name, because the solib.c doesn't know a
thing about each solib's struct lm_info implementation.  Then
again, I only suggested to add the image base to the output
because it was handy...  Anyway, I've already spent more time
in this thread than it takes to add debug output locally
every time I'd need it.  It's in Pierre's court to argue.  ;-)

-- 
Pedro Alves

RE: [RFA-v3] win32-nat.c: Add dll names if debugevents is on

[Pierre Muller]

Hi Christopher,

  I don't debug dynamically linked executables
on other systems than Windows, thus I can't answer your question.

  The reason for adding this is simple:
the change only affects debugevents option,
which is off by default, thus I want that debug option to
give me as useful information as possible.

  But until now, we get an EVENT for dll loading,
but we do not know which dll was loaded, and idem for unloading.
  The added value of this patch is that you can see 
which dll were loaded/unloaded without need to interrupt the
debuggee and use 'info dll'.

  It might be a good thing to have the same for other targets,
but this is not my priority... 
  I mainly use cygwin/mingw32 gdb and I am trying to 
get better results for those targets.



Pierre Muller
Pascal language support maintainer for GDB


  

-----Message d'origine-----
De : gdb-patches-owner@sourceware.org
[mailto:gdb-patches-owner@sourceware.org] De la part de Christopher Faylor
Envoyé : Monday, June 16, 2008 12:54 AM
À : gdb-patches@sourceware.org
Objet : Re: [RFA-v3] win32-nat.c: Add dll names if debugevents is on

On Sat, Jun 14, 2008 at 01:07:12AM +0200, Pierre Muller wrote:
> Thanks Pedro,
>
>  this is my trouble as I am mainly a pascal programmer: 
>I am always lost in implicit typecast/conversion rules :(
>
>  The patch is thus even simpler:

I guess my basic question here is why is this needed at all?  Does
the non-windows version of gdb have something similar?  If so, this
should be patterned after that.  If not, why is Windows special?

cgf

Re: [RFA-v3] win32-nat.c: Add dll names if debugevents is on

[Christopher Faylor]

On Mon, Jun 16, 2008 at 04:32:06AM +0100, Pedro Alves wrote:
>A Sunday 15 June 2008 23:53:30, Christopher Faylor wrote:
>
>> I guess my basic question here is why is this needed at all?  Does
>> the non-windows version of gdb have something similar?  If so, this
>> should be patterned after that.  If not, why is Windows special?
>
>Well, with set "set verbose 1" you can see dll names being
>read in already, but you also get a lot more.  This is just a
>couple of lines to add some debug output.  Note that it
>can't be much patterned (without some extra hair) other than
>printing the so name, because the solib.c doesn't know a
>thing about each solib's struct lm_info implementation.  Then
>again, I only suggested to add the image base to the output
>because it was handy...  Anyway, I've already spent more time
>in this thread than it takes to add debug output locally
>every time I'd need it.  It's in Pierre's court to argue.  ;-)

Ok.  This is the kind of response I was looking for.

I'd like to have as little special case stuff in gdb as possible.  We
have been moving in that direction and that's good.

"set debugevents" is a special case behavior for Windows gdb.  I didn't
add it and I've wondered why it was necessary in the first place since I
don't recall ever feeling its lack on linux.

However, I guess I'll approve the patch since I can see why it would be
useful to have this information and it doesn't seem like there is
anything else that could be pressed into service in gdb-proper.

cgf

Re: [RFA-v3] win32-nat.c: Add dll names if debugevents is on

[Christopher Faylor]

On Tue, Jun 17, 2008 at 12:23:51AM -0400, Christopher Faylor wrote:
>On Mon, Jun 16, 2008 at 04:32:06AM +0100, Pedro Alves wrote:
>>A Sunday 15 June 2008 23:53:30, Christopher Faylor wrote:
>>
>>> I guess my basic question here is why is this needed at all?  Does
>>> the non-windows version of gdb have something similar?  If so, this
>>> should be patterned after that.  If not, why is Windows special?
>>
>>Well, with set "set verbose 1" you can see dll names being
>>read in already, but you also get a lot more.  This is just a
>>couple of lines to add some debug output.  Note that it
>>can't be much patterned (without some extra hair) other than
>>printing the so name, because the solib.c doesn't know a
>>thing about each solib's struct lm_info implementation.  Then
>>again, I only suggested to add the image base to the output
>>because it was handy...  Anyway, I've already spent more time
>>in this thread than it takes to add debug output locally
>>every time I'd need it.  It's in Pierre's court to argue.  ;-)
>
>Ok.  This is the kind of response I was looking for.
>
>I'd like to have as little special case stuff in gdb as possible.  We
                                                 ^
                                       the windows version of
>have been moving in that direction and that's good.

cgf

Re: [RFA-v3] win32-nat.c: Add dll names if debugevents is on

[Pierre Muller]

Christopher Faylor <cgf-use-the-mailinglist-please@sourceware.org> a écrit :

> On Mon, Jun 16, 2008 at 04:32:06AM +0100, Pedro Alves wrote:
>> A Sunday 15 June 2008 23:53:30, Christopher Faylor wrote:
>>
>>> I guess my basic question here is why is this needed at all?  Does
>>> the non-windows version of gdb have something similar?  If so, this
>>> should be patterned after that.  If not, why is Windows special?
>>
>> Well, with set "set verbose 1" you can see dll names being
>> read in already, but you also get a lot more.  This is just a
>> couple of lines to add some debug output.  Note that it
>> can't be much patterned (without some extra hair) other than
>> printing the so name, because the solib.c doesn't know a
>> thing about each solib's struct lm_info implementation.  Then
>> again, I only suggested to add the image base to the output
>> because it was handy...  Anyway, I've already spent more time
>> in this thread than it takes to add debug output locally
>> every time I'd need it.  It's in Pierre's court to argue.  ;-)
>
> Ok.  This is the kind of response I was looking for.
>
> I'd like to have as little special case stuff in gdb as possible.  We
> have been moving in that direction and that's good.
>
> "set debugevents" is a special case behavior for Windows gdb.  I didn't
> add it and I've wondered why it was necessary in the first place since I
> don't recall ever feeling its lack on linux.
>
> However, I guess I'll approve the patch since I can see why it would be
> useful to have this information and it doesn't seem like there is
> anything else that could be pressed into service in gdb-proper.

Christopher,
   you didn't reply to my answer to your first email in that thread,
http://sourceware.org/ml/gdb-patches/2008-06/msg00306.html
and I am quite confused by your wording?
   Should I understand this as an approval?
Or is it just because you did not see my reply?
   In that case, is it because I did not send to you?
   I always suppress your email from the recipients
because of the use-the-mailinglist suffix, but maybe you only mean
that we should never reply only personnally to you?


Pierre Muller
GDB pascal language maintainer

Re: [RFA-v3] win32-nat.c: Add dll names if debugevents is on

[Christopher Faylor]

On Wed, Jun 18, 2008 at 12:19:33AM +0200, Pierre Muller wrote:
> Christopher Faylor <cgf-use-the-mailinglist-please@sourceware.org> a ?crit 
> :
>
>> On Mon, Jun 16, 2008 at 04:32:06AM +0100, Pedro Alves wrote:
>>> A Sunday 15 June 2008 23:53:30, Christopher Faylor wrote:
>>>
>>>> I guess my basic question here is why is this needed at all?  Does
>>>> the non-windows version of gdb have something similar?  If so, this
>>>> should be patterned after that.  If not, why is Windows special?
>>>
>>> Well, with set "set verbose 1" you can see dll names being
>>> read in already, but you also get a lot more.  This is just a
>>> couple of lines to add some debug output.  Note that it
>>> can't be much patterned (without some extra hair) other than
>>> printing the so name, because the solib.c doesn't know a
>>> thing about each solib's struct lm_info implementation.  Then
>>> again, I only suggested to add the image base to the output
>>> because it was handy...  Anyway, I've already spent more time
>>> in this thread than it takes to add debug output locally
>>> every time I'd need it.  It's in Pierre's court to argue.  ;-)
>>
>> Ok.  This is the kind of response I was looking for.
>>
>> I'd like to have as little special case stuff in gdb as possible.  We
>> have been moving in that direction and that's good.
>>
>> "set debugevents" is a special case behavior for Windows gdb.  I didn't
>> add it and I've wondered why it was necessary in the first place since I
>> don't recall ever feeling its lack on linux.
>>
>> However, I guess I'll approve the patch since I can see why it would be
>> useful to have this information and it doesn't seem like there is
>> anything else that could be pressed into service in gdb-proper.
>
> Christopher,
>   you didn't reply to my answer to your first email in that thread,
> http://sourceware.org/ml/gdb-patches/2008-06/msg00306.html
> and I am quite confused by your wording?

"I guess I'll approve the patch" means that the patch is approved with
the reservations that I expressed in my message.

>Should I understand this as an approval?  Or is it just because you did
>not see my reply?  I always suppress your email from the recipients
>because of the use-the-mailinglist suffix, but maybe you only mean that
>we should never reply only personnally to you?

I saw your reply.  It reexplained what you were doing and opined that it
might be good for other targets, which was not what I asked.  Pedro
actually answered the question so I responded to him.

cgf

RE: [RFA-v3] win32-nat.c: Add dll names if debugevents is on

[Pierre Muller]

> > Christopher,
> >   you didn't reply to my answer to your first email in that thread,
> > http://sourceware.org/ml/gdb-patches/2008-06/msg00306.html
> > and I am quite confused by your wording?
> 
> "I guess I'll approve the patch" means that the patch is approved with
> the reservations that I expressed in my message.

  Thanks for the approval,
I committed the patch.
 
> >Should I understand this as an approval?  Or is it just because you
> did
> >not see my reply?  I always suppress your email from the recipients
> >because of the use-the-mailinglist suffix, but maybe you only mean
> that
> >we should never reply only personnally to you?
> 
> I saw your reply.  It reexplained what you were doing and opined that
> it
> might be good for other targets, which was not what I asked.  Pedro
> actually answered the question so I responded to him.

  Sorry to have bothered you even more than usual...


Pierre Muller
Pascal language support maintainer for GDB