Re: GDB HEAD (partly) broken for GNU/Hurd

[Thomas Schwinge <tschwinge@gnu.org>]

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

Hello!

On Thu, Oct 09, 2008 at 12:55:16PM +0100, Pedro Alves wrote:
> A Thursday 09 October 2008 10:34:24, Thomas Schwinge escreveu:
> > Some of the changes that have been installed between gdb_6_8-branch and
> > HEAD cause GDB to no longer function properly on GNU/Hurd under certain
> > circumstances.
> > 
> >     tschwinge@zoobar:~/tmp/gdb/HEAD.build $ gdb/gdb ~/tmp/n1/hurd/ext2fs.static
> >     GNU gdb 6.8.0.20081008-cvs
> >     [...]
> >     This GDB was configured as "i386-unknown-gnu0.3"...
> >     (gdb) r
> >     Starting program: /media/data/home/tschwinge/tmp/n1/hurd/ext2fs.static
> >     [New thread 8112.1]
> >     [New thread 8112.2]
> >     [New thread 8112.3]
> >     [New thread 8112.4]
> >     [New thread 8112.5]
> >     
> >     Program received signal SIGSEGV, Segmentation fault.
> >     convert_options (argp=0x813f0bc, parent=0x0, parent_index=0, group=0x81712e8, cvt=0x101fad0) at argp.h:579
> >     579     argp.h: No such file or directory.
> >             in argp.h
> > 
> >     tschwinge@zoobar:~/tmp/gdb/HEAD.build $ gdb/gdb ~/tmp/n1/hurd/ext2fs.static
> >     GNU gdb (GDB) 6.8.50.20081009-cvs
> >     [...]
> >     (gdb) r
> >     Starting program: /media/data/home/tschwinge/tmp/n1/hurd/ext2fs.static
> >     Can't fetch registers from thread bogus thread id 1: No such thread
> > 
> > Both have been built (natively) on the same up-to-date Debian GNU/Hurd
> > system.
> > 
> > For easy reproduction, I can publish the faulting binary.
> 
> Could you check what caused the breakage?  It *may* have been the ptid
> changes I made, or not.
> 
> 2008-09-08  Pedro Alves  <pedro@codesourcery.com>
> 
>         Use ptid_t.tid to store thread ids instead of ptid_t.pid.

That's not it.  But I bisected it down to this change:

2008-09-11  Ulrich Weigand  <uweigand@de.ibm.com>

	* fork-child.c (startup_inferior): Use target_wait and target_resume
	directly instead of calling wait_for_inferior / resume.

On HEAD, when undoing this change (and additionally commenting out the
two ``stop_soon = X'' lines in that file), things are fine again.

As most of GDB's internals are a big black box to me, I need help here.
:-)

Here is the ext2fs.static binary (bzip2ed) exhibiting the above problem:
<http://www.thomas.schwinge.homeip.net/tmp/ext2fs.static.bz2>.  (Please
bear with the poor upload bandwidth on my side.)


Regards,
 Thomas

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