Re: gdbserver (was Re: parcelling up struct gdbarch)

[Daniel Jacobowitz <dmj+ at andrew dot cmu dot edu>]

On Tue, Jul 17, 2001 at 02:23:52AM +0200, Fabrice Gautier wrote:
> 
> On Mon, 16 Jul 2001 15:40:24 -0700
> Daniel Jacobowitz <dmj+@andrew.cmu.edu> wrote:
> 
> > More specifically, right now my attempt is to get any gdbserver working
> > in the exceedingly limited time frame before gdb 5.1 is released
> > without gdbserver support for the majority of targets.  I can't even
> > test many of the targets gdbserver claims support for, but I have some
> > severe doubts about when they last worked.  If we can hash out the
> > other portion of this thread, hopefully I can get at least Linux
> > working again.
> 
> Hi,
> 
> My personnal focus is to be abble to debug thread apps with gdbserver on
> linux-x86.
> 
> Fortunately for me, gdbserver still compile and works for linux-x86.

My understanding is that Michael Snyder has some bits to do this that
can not be released to the public.  Once I sort through making
gdbserver actually builds on the architectures I'm trying to support
(right now ARM, MIPS, PPC, x86, and soon Sparc and SH), if he still had
not been cleared to release them I was going to do it myself.  Of
course, if you beat me to it, I'll be thrilled :)

> So i've been in the (difficult) process of dissecting gdb to understand
> how that was supposed to be done and i've come down to three things to
> be done:
> 
> 1/ Make mywait in low-linux.c acts more or less like lin_lwp_wait does.
> 2/ Add support for thread query packet.
> 3/ Add thread information in T packets.

You'll also need the equivalent of proc_service.c in order to supply
enough information, I think, and possibly a little more work on the
qSymbol support for that (not sure if the gdbserver side of that
extension was really done/committed).

> In the current gdbserver, when a new pthread is created, gdbserver sends
> a T packet and the host gdb receive a SIGPWR signal. And i have to type
> c to continue.
> 
> I guess gdbserver must send a T packet when a trhead is created so that
> gdb knows about it, so im' wondering how to do so that gdb doesn't stop
> everytime a new thread is created ?

SIGPWR is because that happens to be 32 in the TARGET_SIGNAL_* enum. 
It's really receiving SIGRT0, which is used for the thread manager. 
gdbserver should be sending portable signal numbers, according to the
protocol, but currently does not.  It's on my list of things to fix if
no one beats me to it :)

Eventually GDB will acknowledge the SIGRT0 and then go update its
knowledge of the thread state.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer