Patch to enable a fully working gdb for GNU/Hurd

Patch to enable a fully working gdb for GNU/Hurd

[Svante Signell]

Dear list,

Here is an attempt to create a complete patch for gdb to make it run
successfully on GNU/Hurd.

Problem description:
When starting gdb the following output is written:
Can't fetch registers from thread bogus thread id 1: No such thread

This makes gdb completely unusable for debugging purposes without this
patch.

Patch size: Small change

ChangeLog:
gdb/
2011-06-29 Svante Signell <svante.signell@telia.com> 

 * gnu_nat.c: Activate prune_threads() for Hurd
 * thread.c: Make prune_threads() visible outside current scope.
 * gdbthread.h: Declare prune_threads()
 * Fix PR gdb/12222

gdb-7.2.patch
--- gdb-7.2/gdb/gnu-nat.c.orig	2010-05-14 22:17:37.000000000 +0200
+++ gdb-7.2/gdb/gnu-nat.c	2011-03-28 09:07:49.000000000 +0200
@@ -1578,8 +1578,8 @@
 	  if (--inf->pending_execs == 0)
 	    /* We're done!  */
 	    {
+	      prune_threads ();	/* Get rid of the old shell threads */
 #if 0				/* do we need this? */
-	      prune_threads (1);	/* Get rid of the old shell threads */
 	      renumber_threads (0);	/* Give our threads reasonable names. */
 #endif
 	    }
--- gdb-7.2/gdb/thread.c.orig	2010-08-06 21:51:49.000000000 +0200
+++ gdb-7.2/gdb/thread.c	2011-03-28 09:04:52.000000000 +0200
@@ -61,7 +61,6 @@
 static void info_threads_command (char *, int);
 static void thread_apply_command (char *, int);
 static void restore_current_thread (ptid_t);
-static void prune_threads (void);
 
 /* Frontend view of the thread state.  Possible extensions: stepping,
    finishing, until(ling),...  */
@@ -518,7 +517,7 @@
   return 1;
 }
 
-static void
+void
 prune_threads (void)
 {
   struct thread_info *tp, *next;
--- gdb-7.2/gdb/gdbthread.h.orig	2010-01-12 22:40:24.000000000 +0100
+++ gdb-7.2/gdb/gdbthread.h	2011-03-28 09:03:55.000000000 +0200
@@ -213,6 +213,9 @@
 /* Delete an existing thread list entry.  */
 extern void delete_thread (ptid_t);
 
+/* Prune inactive threads  */
+extern void prune_threads (void);
+
 /* Delete an existing thread list entry, and be quiet about it.  Used
    after the process this thread having belonged to having already
    exited, for example.  */

Re: Patch to enable a fully working gdb for GNU/Hurd

[Thomas Schwinge]

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

Hallo!

On Wed, 29 Jun 2011 19:14:02 +0200, Svante Signell <svante.signell@telia.com> wrote:
> Here is an attempt to create a complete patch for gdb to make it run
> successfully on GNU/Hurd.
> 
> Problem description:
> When starting gdb the following output is written:
> Can't fetch registers from thread bogus thread id 1: No such thread
> 
> This makes gdb completely unusable for debugging purposes without this
> patch.
> 
> Patch size: Small change
> 
> ChangeLog:
> gdb/
> 2011-06-29 Svante Signell <svante.signell@telia.com> 
> 
>  * gnu_nat.c: Activate prune_threads() for Hurd
>  * thread.c: Make prune_threads() visible outside current scope.
>  * gdbthread.h: Declare prune_threads()
>  * Fix PR gdb/12222

At the time I had originally written this patch, I rather considered it
to be a hack than a proper fix -- I just needed a functional GDB on
GNU/Hurd back then.

I think that update_thread_list (which already is exported) should rather
be invoked instead of additionally exporting prune_threads.

But -- I can no longer reproduce the original problem with GDB HEAD.  Can
you?


Grüße,
 Thomas

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

Re: Patch to enable a fully working gdb for GNU/Hurd

[Svante Signell]

On Mon, 2011-07-04 at 20:18 +0200, Thomas Schwinge wrote:
> Hallo!
> 
> On Wed, 29 Jun 2011 19:14:02 +0200, Svante Signell <svante.signell@telia.com> wrote:
> > Here is an attempt to create a complete patch for gdb to make it run
> > successfully on GNU/Hurd.
> > 
> > Problem description:
> > When starting gdb the following output is written:
> > Can't fetch registers from thread bogus thread id 1: No such thread
> > 
> > This makes gdb completely unusable for debugging purposes without this
> > patch.
> > 
> > Patch size: Small change
> > 
> > ChangeLog:
> > gdb/
> > 2011-06-29 Svante Signell <svante.signell@telia.com> 
> > 
> >  * gnu_nat.c: Activate prune_threads() for Hurd
> >  * thread.c: Make prune_threads() visible outside current scope.
> >  * gdbthread.h: Declare prune_threads()
> >  * Fix PR gdb/12222
> 
> At the time I had originally written this patch, I rather considered it
> to be a hack than a proper fix -- I just needed a functional GDB on
> GNU/Hurd back then.
> 
> I think that update_thread_list (which already is exported) should rather
> be invoked instead of additionally exporting prune_threads.
> 
> But -- I can no longer reproduce the original problem with GDB HEAD.  Can
> you?

I haven't compiled gdb for some time now. I can take a look, how to get
the GDB HEAD? The prune_threads enabled gdb to work properly, and then
Samuel applied an earlier version of the patch on debian-ports.

Since then the new Debian gdb maintainer wanted to get this patch
applied upstream, so I did as was requested. Don't know if it is the
correct approach or not. I can try to use update_thread_list instead,
once I have the GDB HEAD files.

 

Re: Patch to enable a fully working gdb for GNU/Hurd

[Joel Brobecker]

> I haven't compiled gdb for some time now. I can take a look, how to get
> the GDB HEAD?

You have a choice between CVS or GIT:
http://www.sourceware.org/gdb/current/

-- 
Joel

Re: Patch to enable a fully working gdb for GNU/Hurd

[Svante Signell]

On Mon, 2011-07-04 at 21:17 +0200, Svante Signell wrote:
> On Mon, 2011-07-04 at 20:18 +0200, Thomas Schwinge wrote:
> > Hallo!
...
> > I think that update_thread_list (which already is exported) should rather
> > be invoked instead of additionally exporting prune_threads.
> > 
> > But -- I can no longer reproduce the original problem with GDB HEAD.  Can
> > you?
> 
> I haven't compiled gdb for some time now. I can take a look, how to get
> the GDB HEAD? The prune_threads enabled gdb to work properly, and then
> Samuel applied an earlier version of the patch on debian-ports.
> 
> Since then the new Debian gdb maintainer wanted to get this patch
> applied upstream, so I did as was requested. Don't know if it is the
> correct approach or not. I can try to use update_thread_list instead,
> once I have the GDB HEAD files.

I have now built gdb HEAD and found that the patch is no longer needed.
Additionally adding update_thread_list in gnu_nat.c works for gdb-7.2,
will propose the following patch to the Debian bug report #579834 in
case there will be more releases of the 7.2-series until 7.4 is
released.

--- gdb/gnu-nat.c.orig  2011-07-05 15:41:54.000000000 +0200
+++ gdb/gnu-nat.c       2011-07-05 14:27:31.000000000 +0200
@@ -1578,6 +1578,7 @@
          if (--inf->pending_execs == 0)
            /* We're done!  */
            {
+             update_thread_list();
 #if 0                          /* do we need this? */
              prune_threads (1);        /* Get rid of the old shell
threads */
              renumber_threads (0);     /* Give our threads reasonable
names. */

A few observations when building gdb HEAD: GNU gdb (GDB)
7.3.50.20110704-cvs though:

1) I had to uncomment -Werror when compiling gdb/msg_U.c with Debian
4.6.1-1+hurd.1 due to the -Wstrict-aliasing flag set by -Wall, see
below:

msg_U.c: In function 'msg_del_auth':
msg_U.c:505:3: error: dereferencing type-punned pointer will break
strict-aliasing rules [-Werror=strict-aliasing]
msg_U.c:520:3: error: dereferencing type-punned pointer will break
strict-aliasing rules [-Werror=strict-aliasing]
msg_U.c: In function 'msg_get_init_ports':
msg_U.c:957:6: error: dereferencing type-punned pointer will break
strict-aliasing rules [-Werror=strict-aliasing]
msg_U.c: In function 'msg_set_init_ports':
msg_U.c:1050:3: error: dereferencing type-punned pointer will break
strict-aliasing rules [-Werror=strict-aliasing]
msg_U.c: In function 'msg_get_init_ints':
msg_U.c:1481:6: error: dereferencing type-punned pointer will break
strict-aliasing rules [-Werror=strict-aliasing]
msg_U.c: In function 'msg_set_init_ints':
msg_U.c:1573:3: error: dereferencing type-punned pointer will break
strict-aliasing rules [-Werror=strict-aliasing]
msg_U.c: In function 'msg_get_dtable':
msg_U.c:1739:6: error: dereferencing type-punned pointer will break
strict-aliasing rules [-Werror=strict-aliasing]
msg_U.c: In function 'msg_set_dtable':
msg_U.c:1832:3: error: dereferencing type-punned pointer will break
strict-aliasing rules [-Werror=strict-aliasing]
msg_U.c: In function 'msg_get_environment':
msg_U.c:2253:6: error: dereferencing type-punned pointer will break
strict-aliasing rules [-Werror=strict-aliasing]
msg_U.c: In function 'msg_set_environment':
msg_U.c:2345:3: error: dereferencing type-punned pointer will break
strict-aliasing rules [-Werror=strict-aliasing]
msg_U.c: In function 'msg_get_env_variable':
msg_U.c:2511:6: error: dereferencing type-punned pointer will break
strict-aliasing rules [-Werror=strict-aliasing]
msg_U.c: In function 'msg_describe_ports':
msg_U.c:3018:3: error: dereferencing type-punned pointer will break
strict-aliasing rules [-Werror=strict-aliasing]
msg_U.c:3083:6: error: dereferencing type-punned pointer will break
strict-aliasing rules [-Werror=strict-aliasing]
cc1: all warnings being treated as errors

2) When debugging an executable gdb does not find the debugging symbols
for libraries. For example with libc0.3-dbg installed, the symbols are
found with 7.2 but not with 7.3.50 when running the built gdb directly
on an executable having debugging symbols (they are found).

Re: Patch to enable a fully working gdb for GNU/Hurd

[Thomas Schwinge]

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

Hallo!

On Tue, 05 Jul 2011 16:38:04 +0200, Svante Signell <svante.signell@telia.com> wrote:
> On Mon, 2011-07-04 at 21:17 +0200, Svante Signell wrote:
> > On Mon, 2011-07-04 at 20:18 +0200, Thomas Schwinge wrote:
> > > I think that update_thread_list (which already is exported) should rather
> > > be invoked instead of additionally exporting prune_threads.
> > > 
> > > But -- I can no longer reproduce the original problem with GDB HEAD.  Can
> > > you?
> > 
> > I haven't compiled gdb for some time now. I can take a look, how to get
> > the GDB HEAD? The prune_threads enabled gdb to work properly, and then
> > Samuel applied an earlier version of the patch on debian-ports.
> > 
> > Since then the new Debian gdb maintainer wanted to get this patch
> > applied upstream, so I did as was requested. Don't know if it is the
> > correct approach or not. I can try to use update_thread_list instead,
> > once I have the GDB HEAD files.
> 
> I have now built gdb HEAD and found that the patch is no longer needed.

OK, and thanks for confirming!  Thus, I'll close the GDB PR.


> Additionally adding update_thread_list in gnu_nat.c works for gdb-7.2,
> will propose the following patch to the Debian bug report #579834 in
> case there will be more releases of the 7.2-series until 7.4 is
> released.

Either that, or simply continue to use the patch we're currently using
(no additional work for the Debian maintainers).  The existing patch
doesn't do any harm, and can then simply be dropped once Debian is
switching to a GDB release that no longer requires the patch -- which is
still to be determined.


> A few observations when building gdb HEAD: GNU gdb (GDB)
> 7.3.50.20110704-cvs though:
> 
> 1) I had to uncomment -Werror when compiling gdb/msg_U.c with Debian
> 4.6.1-1+hurd.1 due to the -Wstrict-aliasing flag set by -Wall, see
> below:
> 
> msg_U.c: In function 'msg_del_auth':
> msg_U.c:505:3: error: dereferencing type-punned pointer will break
> strict-aliasing rules [-Werror=strict-aliasing]

This issue is known: search for ``werror'' on
<http://www.bddebian.com/~hurd-web/open_issues/gdb/>.


> 2) When debugging an executable gdb does not find the debugging symbols
> for libraries. For example with libc0.3-dbg installed, the symbols are
> found with 7.2 but not with 7.3.50 when running the built gdb directly
> on an executable having debugging symbols (they are found).

I would guess this is not Hurd-specific, but is due to Debian's multiarch
changes, and is thus a general problem.


Grüße,
 Thomas

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

Re: Patch to enable a fully working gdb for GNU/Hurd

[Tom Tromey]

>>>>> "Svante" == Svante Signell <svante.signell@telia.com> writes:

Svante> 2) When debugging an executable gdb does not find the debugging symbols
Svante> for libraries. For example with libc0.3-dbg installed, the symbols are
Svante> found with 7.2 but not with 7.3.50 when running the built gdb directly
Svante> on an executable having debugging symbols (they are found).

If libc0.3-dbg is just the separate debuginfo package, then make sure
you have configured gdb with the correct --with-separate-debug-dir.

Tom

Re: Patch to enable a fully working gdb for GNU/Hurd

[Svante Signell]

On Tue, 2011-07-05 at 10:15 -0600, Tom Tromey wrote:
> >>>>> "Svante" == Svante Signell <svante.signell@telia.com> writes:
> 
> Svante> 2) When debugging an executable gdb does not find the debugging symbols
> Svante> for libraries. For example with libc0.3-dbg installed, the symbols are
> Svante> found with 7.2 but not with 7.3.50 when running the built gdb directly
> Svante> on an executable having debugging symbols (they are found).
> 
> If libc0.3-dbg is just the separate debuginfo package, then make sure
> you have configured gdb with the correct --with-separate-debug-dir.

Looks like the following are set in the Debian case:
#define DEBUGDIR "/usr/lib/debug"
#define DEBUGDIR_RELOCATABLE 1

The difference with my build was that only --prefix=/usr was set
resulting in

#define DEBUGDIR "/usr/local/lib/debug"

Thanks, problem solved!