From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Jacobowitz To: Fabrice Gautier Cc: Andrew Cagney , jtc@redback.com, gdb@sources.redhat.com Subject: Re: gdbserver (was Re: parcelling up struct gdbarch) Date: Mon, 16 Jul 2001 21:17:00 -0000 Message-id: <20010716211743.A28384@nevyn.them.org> References: <3B536B0C.3060908@cygnus.com> <20010716154024.A9181@nevyn.them.org> <20010717012923.F61A.GAUTIER@email.enst.fr> X-SW-Source: 2001-07/msg00195.html On Tue, Jul 17, 2001 at 02:23:52AM +0200, Fabrice Gautier wrote: > > On Mon, 16 Jul 2001 15:40:24 -0700 > Daniel Jacobowitz 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