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

["Korbel, Michal" <Michal dot Korbel at intel dot com>]

Hi,
In this week I plan create own version of GDBSERVER.
This version to be abble to debug thread apps only on linux-x86 (in the end
of year I plan create STRONG ARM support).
This version base on i386-stub from Quality Quorum and Michael Synder
qSymbol packet support.

Current status is:
	support thread packet (qC with reply QC, qP with reply qQ, qL with
reply QM),
	support Zbreak packet (software breakpoint),
	support P packet (write register),
	support Hg packet (set general thread).
	support Standard Responses
	support Mandatory Requests

How to use:
on target side call: gdbserver <connection> <program_to_debug>
<args_program_to_debug>
on host side call: gdb			# (gdb version with support qSymbol
packet - check remote.c file revision 1.55)
on gdb: target remote <connection>
on gdb: symbol <program_to_debug>
on gdb: break <break_description>	# (now we can insert own breakpoint)
on gdb: continue				# (now we can all we need)

I can switch to another thread and use step or next command,
but I have problem when try use continue all thread (plan finish today).
When I change support own version mywait funtion I hope will be better.

----------------------------------------------------------------------------
----------
Michal Korbel - Software engineer
Intel Technology Poland Sp. z o.o.; ul. Slowackiego 173; 80-298 Gdansk
tel. +48 58 34-81-726; fax: +48 58 34-81-505; mobile:+48 603-203-142 
----------------------------------------------------------------------------
----------

-----Original Message-----
From: Daniel Jacobowitz [mailto:dmj+@andrew.cmu.edu]
Sent: Tuesday, July 17, 2001 6:18 AM
To: Fabrice Gautier
Cc: Andrew Cagney; jtc@redback.com; gdb@sources.redhat.com
Subject: Re: gdbserver (was Re: parcelling up struct gdbarch)

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