Re: Missing a step in new(er) Remote gdb/kdb setup?

In case this info might be a clue:

lonnie_at_aperiodic$ ident /usr/bin/kgdb
/usr/bin/kgdb:
     $FreeBSD: src/lib/csu/i386-elf/crti.S,v 1.6 2002/05/15 04:19:49 obrien 
Exp $
     $FreeBSD: src/usr.bin/yacc/skeleton.c,v 1.37 2003/02/12 18:03:55 davidc 
Exp $
     $FreeBSD: src/usr.bin/yacc/skeleton.c,v 1.37 2003/02/12 18:03:55 davidc 
Exp $
     $FreeBSD: src/usr.bin/yacc/skeleton.c,v 1.37 2003/02/12 18:03:55 davidc 
Exp $
     $FreeBSD: src/usr.bin/yacc/skeleton.c,v 1.37 2003/02/12 18:03:55 davidc 
Exp $
     $FreeBSD: src/usr.bin/yacc/skeleton.c,v 1.37 2003/02/12 18:03:55 davidc 
Exp $
     $FreeBSD: src/usr.bin/yacc/skeleton.c,v 1.37 2003/02/12 18:03:55 davidc 
Exp $
     $FreeBSD: src/lib/csu/i386-elf/crtn.S,v 1.5 2002/05/15 04:19:49 obrien 
Exp $
     $FreeBSD: src/lib/csu/common/crtbrand.c,v 1.4 2003/10/17 15:43:13 peter 
Exp $
     $FreeBSD: src/lib/csu/i386-elf/crt1.c,v 1.13 2004/08/15 16:18:51 dfr Exp 
$
     $FreeBSD: src/gnu/usr.bin/gdb/kgdb/kthr.c,v 1.1.2.1 2005/03/01 20:35:14 
obrien Exp $
     $FreeBSD: src/gnu/usr.bin/gdb/kgdb/main.c,v 1.2.2.4 2005/03/14 20:49:04 
marcel Exp $
     $FreeBSD: src/gnu/usr.bin/gdb/kgdb/trgt.c,v 1.1.2.1 2005/03/01 20:35:14 
obrien Exp $
     $FreeBSD: src/gnu/usr.bin/gdb/kgdb/trgt_i386.c,v 1.1.2.1 2005/03/01 
20:35:14 obrien Exp $

On Thursday 11 August 2005 10:09 am, Lonnie VanZandt wrote:
> Marcel,
>
> 	The protocol sync issue is now gone - but the host side kgdb core dumps
> immediately after reporting the current break point of the target:
>
> lonnie_at_aperiodic$ kgdb -r /dev/cuaa0 /tmp/kernel.debug
> [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
> Undefined symbol "ps_pglobal_lookup"]
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you
> are welcome to change it and/or distribute copies of it under certain
> conditions. Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i386-marcel-freebsd".
> (no debugging symbols found)...Switching to remote protocol
> 0xc0634d14 in kdb_enter ()
> Segmentation fault (core dumped)
>
> If I run gdb on the kgdb.core file, it shows a corrupted - or at least
> massive - stack frame with no symbolic information.
>
> Is there a kgdb patch/update for 5.4 release p3 that I should apply? Or
> perhaps some permission/resource issue on the host that needs to be
> corrected?
>
> On Thursday 04 August 2005 06:10 pm, Marcel Moolenaar wrote:
> > On Aug 4, 2005, at 9:27 AM, Lonnie VanZandt wrote:
> > > Ok, so I infer that the startup sequence should be:
> > >
> > >     1. enter kdb on target
> > >     2. type gdb on target
> > >     3. type s on target
> > >     4. start kgdb on host with -r option
> > >     5. wait for good connection
> > >     6. load symbol table files on host
> > >     7. get on with the debugging
> > >
> > > Is this correct?
> >
> > Yes.
> >
> > > (There was not this requirement for strict ordering in the
> > > prior version of the remote protocol - or else it was at least more
> > > tolerant)
> >
> > I think the problem is that on the one hand the kernel sends a packet to
> > inform GDB that it has stopped and on the other hand GDB sends various
> > packets to figure out what the target is capable of. When this happens
> > at the same time, GDB gets confused. There has not been a change in KDB
> > and the GDB backend that makes this worse than before. It's all because
> > of a new version of GDB.
> >
> > FYI,
>
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"