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

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

[Korbel, Michal]

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

Re: parcelling up struct gdbarch

[Andrew Cagney]

> 
> Andrew> If GDBserver is going to be come more tightly integrated into GDB then
> Andrew> it is going to need to pick up some baggage like ui-file.
> 
> Can you explain your vision (or provide pointers to previous articles)
> of a tightly integrated gdbserver?


My, er ``vision'' is more focused on the target stack.

By tightly integrated I really mean, have gdbserver steal some of what 
GDB currently does.  For instance, imagine (this will take some 
imagination) a GDB with a cleanly implemented single step.

	WFI would tell the target to single step
	(WFI has been fixed to not know about
	h/w or s/w single step)

	the target, since it didn't know how to
	single step, would use software single step
	and tell the next target down to run.

	the remote.c target would get this and
	send it to the server.

	gdbserver would run/stop the target

If GDB and gdbserver share a common framework then it should be possible 
to push layers (such as single step) down into the remote server.

> I expect and accept some baggage,
> but at the moment I cannot comprehend why it would need high level
> constructs like ui-file.


If gdbserver is going to use more chunks of GDB then it and gdb will 
would probably want to start sharing certain bits of infrastructure - 
the event loop, the error output, serial.*

How much can/should be shared, I don't know.

 From what Daniel has said, I gather that his immediate focus is on 
getting a very thin gdbserver working.

	Andrew

Re: parcelling up struct gdbarch

[Daniel Jacobowitz]

On Mon, Jul 16, 2001 at 06:30:36PM -0400, Andrew Cagney wrote:
> If gdbserver is going to use more chunks of GDB then it and gdb will 
> would probably want to start sharing certain bits of infrastructure - 
> the event loop, the error output, serial.*
> 
> How much can/should be shared, I don't know.
> 
>  From what Daniel has said, I gather that his immediate focus is on 
> getting a very thin gdbserver working.

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.

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

gdbserver (was Re: parcelling up struct gdbarch)

[Fabrice Gautier]

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.

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.

For 2/ I guess it will be only old-style queries.
Then 3/ need to be done correctly since this is the only way for the
other side to know about threads. Btw it seems to be mostly done (in
remote-utils.c), strange since there's no support to handle incoming
thread packets, look like this was just a copy/paste from the main gdb. 

Now i'm focusing on studying lin_lwp_wait to see what's going on here...

I'm not sure if what i'm doing now would be usefull for the long-term
evolution of gdbserver but as Daniel, my goal is to have something
working rapidely

If any of you have any ideas about this issue, or if you have done some
work already, please share.

In the meantime i already have a question:

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 ?


Thanks

(Words of support are welcome too :)

-- 
Fabrice Gautier <gautier@email.enstfr>

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

[Daniel Jacobowitz]

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

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

[Fabrice Gautier]

On Mon, 16 Jul 2001 21:17:44 -0700
Daniel Jacobowitz <dmj+@andrew.cmu.edu> wrote:

> 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:
> > 
> > My personnal focus is to be abble to debug thread apps with gdbserver on
> > linux-x86.

> > 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).

I guess alll I need frm proc_service.c is already in lin-lwp.c
(lin_lwp_store_registers, lin_lwp_xfer_memory, etc..)

As for qSymbol support, I haven't found what it's in the docs i have,
but i guess it has something to do with symbols. For now, i'm loading
symbols manually on the host side.

Thanks

-- 
Fabrice Gautier <gautier@email.enstfr>

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

[Daniel Jacobowitz]

On Tue, Jul 17, 2001 at 07:21:19AM +0200, Fabrice Gautier wrote:
> 
> On Mon, 16 Jul 2001 21:17:44 -0700
> Daniel Jacobowitz <dmj+@andrew.cmu.edu> wrote:
> 
> > 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:
> > > 
> > > My personnal focus is to be abble to debug thread apps with gdbserver on
> > > linux-x86.
> 
> > > 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).
> 
> I guess alll I need frm proc_service.c is already in lin-lwp.c
> (lin_lwp_store_registers, lin_lwp_xfer_memory, etc..)
> 
> As for qSymbol support, I haven't found what it's in the docs i have,
> but i guess it has something to do with symbols. For now, i'm loading
> symbols manually on the host side.

No, take a better look at proc_service and thread-db.  Both will need
to be handled in gdbserver.  The child stack calls from lin_lwp call
off through thread-db.


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

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

[Andrew Cagney]

> In the meantime i already have a question:
> 
> 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 ?


FYI,

remote.c assumes that the target is sending back signals encoded as 
GDB's ``enum target_signal''.  This contradicts the documentation which 
says that the target sends back signals in a target dependant way.  More 
doco to fix.

Daniel,

This is a similar problem as for registers.

	Andrew

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

[Daniel Jacobowitz]

On Tue, Jul 17, 2001 at 01:00:36PM -0400, Andrew Cagney wrote:
> > In the meantime i already have a question:
> > 
> > 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 ?
> 
> 
> FYI,
> 
> remote.c assumes that the target is sending back signals encoded as 
> GDB's ``enum target_signal''.  This contradicts the documentation which 
> says that the target sends back signals in a target dependant way.  More 
> doco to fix.
> 
> Daniel,
> 
> This is a similar problem as for registers.

How so?  It seems to me to be a much simpler problem, instead.  It
means that gdbserver needes target_signal_to_host and friends, which is
much easier.  If, that is, we change documentation and gdbserver rather than
remote.c.

In fact I'll submit a patch for this later today.  Would you like me to
separate the code out of target.c and share it between gdb and
gdbserver, or just duplicate it?  It sounds to me that we want to
separate gdbserver further, along better-defined boundaries, so
duplicating it and documenting it would be the way to go.

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

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

[Andrew Cagney]

> 
> How so?  It seems to me to be a much simpler problem, instead.  It
> means that gdbserver needes target_signal_to_host and friends, which is
> much easier.  If, that is, we change documentation and gdbserver rather than
> remote.c.


If gdbserver is going to pass ptrace() (i.e. target dependant) register 
bufers then should it also pass back target dependant signal numbers?

In fact, thinking about it, I know where my comment would have come from 
- I would have looked at gdbserver and tried to document the current 
behavour.  Only later did I notice that the comment was wrong and 
remote.c wasn't doing any conversion :-/

So, which is correct?


	Andrew

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

[Daniel Jacobowitz]

On Tue, Jul 17, 2001 at 02:10:41PM -0400, Andrew Cagney wrote:
> > 
> > How so?  It seems to me to be a much simpler problem, instead.  It
> > means that gdbserver needes target_signal_to_host and friends, which is
> > much easier.  If, that is, we change documentation and gdbserver rather than
> > remote.c.
> 
> 
> If gdbserver is going to pass ptrace() (i.e. target dependant) register 
> bufers then should it also pass back target dependant signal numbers?
> 
> In fact, thinking about it, I know where my comment would have come from 
> - I would have looked at gdbserver and tried to document the current 
> behavour.  Only later did I notice that the comment was wrong and 
> remote.c wasn't doing any conversion :-/
> 
> So, which is correct?

Well, I can argue (and, confusingly, have argued :) both sides here.
I'm not entirely sure.  One advantage of passing target dependent signal
numbers is that if we send a signal that has no target equivalent we
can error before trying to communicate that to the target.  I think
it's outweighed by the fact that a host GDB may not even have the
target's signal numbers available, though.

("But target.c knows them!" you say?  Look where it gets them from -
the host <signal.h>.  The host <signal.h> is wrong for a cross gdb. 
Mind if I add at least a FIXME comment to target.c about this?)

So for signals at least, documentation and gdbserver should change.


For register buffers, see the other half of this thread.

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

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

[Andrew Cagney]

> Well, I can argue (and, confusingly, have argued :) both sides here.
> I'm not entirely sure.  One advantage of passing target dependent signal
> numbers is that if we send a signal that has no target equivalent we
> can error before trying to communicate that to the target.  I think
> it's outweighed by the fact that a host GDB may not even have the
> target's signal numbers available, though.
> 
> ("But target.c knows them!" you say?  Look where it gets them from -
> the host <signal.h>.  The host <signal.h> is wrong for a cross gdb. 
> Mind if I add at least a FIXME comment to target.c about this?)
> 
> So for signals at least, documentation and gdbserver should change.
> 
> 
> For register buffers, see the other half of this thread.


A good rule of thumb is to not mix layers.  Something GDB isn't good at.

There are really two cases:

	target which is a UNIX like

	target which is not UNIX like

In the case of the latter, a fairly arbitrary decision was made to just 
use ``enum target_signal'' signal numberings and some cooked up packet. 
  The signal numbering decision was made on the basis that the protocol 
didn't allow the exchange of arbitrary events (it was to UNIX centric).

	Andrew

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

[Quality Quorum]

Hi, 

The last time I checked multi-threading support in remote.c was
broken - I do not remember exact details by now. 

I tried to make a complete implementation of both sides -

http://world.std.com/~qqi/downloads/i386_stub.tar.gz 

- hope, it will be useful.

I also have an extended gdbserver which supports native targets
on Linux and FreeBsd - 

http://world.std.com/~qqi/downloads/rproxy-0.6.tar.gz

Thanks,

Aleksey