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

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,