A Thursday 09 October 2008 10:34:24, Thomas Schwinge escreveu:
> Hello!
>
> 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.
>
> [EMAIL PROTECTED]:~/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
>
> [EMAIL PROTECTED]:~/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 <[EMAIL PROTECTED]>
Use ptid_t.tid to store thread ids instead of ptid_t.pid.
* gnu-nat.c (inf_validate_procs): If this is the first time we're
seeing a thread id, extend the main thread's ptid. If we still
have pending execs, don't be verbose about new threads.
(gnu_wait, gnu_resume, gnu_attach, gnu_thread_alive)
(gnu_pid_to_str, cur_thread, sig_thread_cmd): Adjust.
* i386gnu-nat.c (gnu_fetch_registers, gnu_store_registers):
Adjust.
If nothing obvious turns up, could you open up a bug report
with a testcase and instructions, please?
--
Pedro Alves
