parcelling up struct gdbarch

parcelling up struct gdbarch

[Daniel Jacobowitz]

For the benefit of gdbserver, as discussed, I'd like to break the struct
into two pieces - call them, hypothetically, gdbarch and gdbarch_native.
Things which gdbserver should be able to share, like PC_REGNUM and other
things relating to register layout, or like CANNOT_FETCH_REGISTER, etc.,
would go in the smaller native struct.  They could be fetched from a (split
off from the existing) target specific file, or temporarily added in the
appropriate low-<arch>.c.

Does this sound reasonable?

Also, as a first step I would like to break the data table out of gdbarch.sh
into a separate file.  Is there any reason not to do this?  Then, rather
than introducing another field, I can introduce a second data file for the
native elements.

Native is perhaps not the best name, as e.g. PC_REGNUM need to be known even
in non-native configurations, but calling it gdbarch_target seems wrong to
me.  I'm open to better naming suggestions.

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

Re: parcelling up struct gdbarch

[Andrew Cagney]

> For the benefit of gdbserver, as discussed, I'd like to break the struct
> into two pieces - call them, hypothetically, gdbarch and gdbarch_native.
> Things which gdbserver should be able to share, like PC_REGNUM and other
> things relating to register layout, or like CANNOT_FETCH_REGISTER, etc.,
> would go in the smaller native struct.  They could be fetched from a (split
> off from the existing) target specific file, or temporarily added in the
> appropriate low-<arch>.c.
> 
> Does this sound reasonable?


To me this seems artificial.  I can understand a split along the lines 
of ISA and ABI but not one justified on the grounds of what gdb-server 
needs.  That feels like putting the cart before the horse.

Could I strongly encourage you to at least try to build a bloated GDB 
server so that you (and everyone else) know what the real problems are. 
  I think you will find that the bloat caused by *-tdep.c will be in the 
noise compared to the other things that are draged in.

Could I also encourage you to examine exactly what information you do 
need from gdbarch.  The big ones that that I know of are 
REGISTER_RAW_SIZE() and REGISTER_BYTE().  The way that they are used to 
construct/destruct a G packet are simply wrong.

To repeat an earlier point, I think there needs to be something outside 
of gdbarch that specifie what a G packet layout is and how that G packet 
is mapped to/from a raw-regnum or a native register.  Remember, the G 
packet is part of an unchanging and public interface (I'll resist the 
temptation to suggest specifying it in ASN.1 :-).


> Also, as a first step I would like to break the data table out of gdbarch.sh
> into a separate file.  Is there any reason not to do this?  Then, rather
> than introducing another field, I can introduce a second data file for the
> native elements.
> 
> Native is perhaps not the best name, as e.g. PC_REGNUM need to be known even
> in non-native configurations, but calling it gdbarch_target seems wrong to
> me.  I'm open to better naming suggestions.


Jut FYI, core GDB should not know about PC_REGNUM.  A given ISA might be 
able to determine the program stop/resume address (returned via 
read_pc()) from a single raw register.  A second ISA might find it 
necessary to construct that same stop/resume address using 4 separate 
raw registers.

	Andrew

Re: parcelling up struct gdbarch

[Daniel Jacobowitz]

On Fri, Jul 13, 2001 at 03:35:27PM -0400, Andrew Cagney wrote:
> > For the benefit of gdbserver, as discussed, I'd like to break the struct
> > into two pieces - call them, hypothetically, gdbarch and gdbarch_native.
> > Things which gdbserver should be able to share, like PC_REGNUM and other
> > things relating to register layout, or like CANNOT_FETCH_REGISTER, etc.,
> > would go in the smaller native struct.  They could be fetched from a (split
> > off from the existing) target specific file, or temporarily added in the
> > appropriate low-<arch>.c.
> > 
> > Does this sound reasonable?
> 
> 
> To me this seems artificial.  I can understand a split along the lines 
> of ISA and ABI but not one justified on the grounds of what gdb-server 
> needs.  That feels like putting the cart before the horse.
> 
> Could I strongly encourage you to at least try to build a bloated GDB 
> server so that you (and everyone else) know what the real problems are. 
>   I think you will find that the bloat caused by *-tdep.c will be in the 
> noise compared to the other things that are draged in.
> 
> Could I also encourage you to examine exactly what information you do 
> need from gdbarch.  The big ones that that I know of are 
> REGISTER_RAW_SIZE() and REGISTER_BYTE().  The way that they are used to 
> construct/destruct a G packet are simply wrong.

Indeed.  The current errors on one typical target - powerpc-linux -
are:

undefined reference to `current_gdbarch'
undefined reference to `gdbarch_cannot_store_register'
undefined reference to `gdbarch_fp_regnum'
undefined reference to `gdbarch_npc_regnum'
undefined reference to `gdbarch_pc_regnum'
undefined reference to `gdbarch_register_byte'
undefined reference to `gdbarch_register_bytes'
undefined reference to `gdbarch_register_raw_size'
undefined reference to `gdbarch_sp_regnum'

There's a couple of culprits:
low-linux.c - fetch_register, store_inferior_registers, and the
allocation of a block large enough to hold all the registers.

server.c - references to REGISTER_BYTES

remote-utils.c - putpkt, outreg, and of course prepare_resume_reply
(which does things like #ifdef NPC_REGNUM, no longer valid at all).


This is ignoring the few things normally in the tdep file, which in
deference to current practice I've just been putting in
machine-dependent sections of low-linux.c.

> To repeat an earlier point, I think there needs to be something outside 
> of gdbarch that specifie what a G packet layout is and how that G packet 
> is mapped to/from a raw-regnum or a native register.  Remember, the G 
> packet is part of an unchanging and public interface (I'll resist the 
> temptation to suggest specifying it in ASN.1 :-).

Thank you :)  The question then becomes, how do we specify this
information in a way that gdbserver and gdb can both make use of it. 
A given GDB may need to support more than one such format, while a
given gdbserver (at this time, at least) only wants to know one.

Here we're back to the original question of whether to bring gdbserver
and gdb closer together or farther apart.  As a more useful test of things
referenced in gdbserver, I replaced the inclusion of "defs.h" in
server.h with a much smaller set of includes.  No nm.h; no xm.h; no
tm.h; no gdbarch.h.  The only things missing were:

  REGISTER_BYTES, KERNEL_U_ADDR, PC_REGNUM, SP_REGNUM, FP_REGNUM

So I could eliminate use of these macros in gdbserver, by documenting
that the low-* files need to provide routines to do the tasks in
remote-utils.c that referenced the macros, and documenting that the
low-* files need to export the size of the register cache or make
server.c unaware of it (that's also a G/g-packet related use, and
pretty easily eliminatable).

Doing it this way enforces clear boundaries, with all the advantages
that implies.  It also increases, to some extent, code duplication.
My position on that has changed a bit as I've been going over the code;
I've come to think that the advantage of boundaries may in fact
outweigh the disadvantages of duplication, especially since we can cut
the duplication down a fair bit by simpling going over the code
(low-linux is in need of some cleanup).

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

Re: parcelling up struct gdbarch

[Andrew Cagney]

> Indeed.  The current errors on one typical target - powerpc-linux -
> are:
> 
> undefined reference to `current_gdbarch'
> undefined reference to `gdbarch_cannot_store_register'
> undefined reference to `gdbarch_fp_regnum'
> undefined reference to `gdbarch_npc_regnum'
> undefined reference to `gdbarch_pc_regnum'
> undefined reference to `gdbarch_register_byte'
> undefined reference to `gdbarch_register_bytes'
> undefined reference to `gdbarch_register_raw_size'
> undefined reference to `gdbarch_sp_regnum'


Live dangerously, try linking against libgdb.a :-)


>   REGISTER_BYTES, KERNEL_U_ADDR, PC_REGNUM, SP_REGNUM, FP_REGNUM


REGISTER_BYTES is hard, I'll ignore it for the moment :-)
KERNEL_U_ADDR lives in nm.h so that one is probably ok.

As for PC_REGNUM, NPC_REGNUM, ... SP_REGNUM and FP_REGNUM, I think we 
need to study a little history.

~'70: Wirth introduces pascal.  By now everyone is convinced that 
procedural languages need a program-counter, stack-pointer, dynamic-link 
and static-link.  Life was good.

~'79: The VAX appears, like everyone else they follow the DL/SL/SP 
mantra and hence the VAX has a stack-pointer and a frame-pointer (DL). 
I don't remember what was done with the static-link but, regardless, 
life was good.

~'84: RMS writes GDB 0.0.  It assumes FP, PC and SP are all raw 
registers.  Live was good.

Unfortunatly, from here on in, things started to go wrong: NPC_REGNUM, 
then NNPC_REGNUM get added, DECR_PC_AFTER_BREAK was added, the MIPS gets 
a bogus FP register and then proceeds to assume it is real, the arm gets 
two FP registers, and finally GDB gets PSEUDO registers.  Things are no 
longer so good. In fact, thanks to DECR_PC_AFTER_BREAK, things are down 
right miserable.

So we turn to now.  Refering to figure ``1'':

>   nat-register layout
>     |
>     |(*-nat.c)
>     |
>   raw register layout
>     |
>     |(*frame*)
>     |
>   cooked register layout

While it's taken 15 years to figure out, I think this is a register 
model that works.  As far as core GDB is concerned PC_REGNUM, FP_REGNUM, 
SP_REGNUM et.al. are all cooked registers.  While for many targets, 
RAW_FP_REGNUM == COOKED_FP_REGNUM, might be true, they are separate.


The gdbserver code that refers to those macros has, has a result of the 
above revalation, become wrong.  The nat code, in general, should refer 
to nat, raw or G register numbering and not cooked registers.  When it 
comes to the registers to pass back with the T packet, I think it should 
be given an explicit list.

--

Looking to the future, PC_REGNUM, will get more interesting.  Core GDB 
has the idea of a stop-address and a continuation-address. 
{read,write}_pc() control this.  If someone ever tries to implement more 
complex operations in gdbserver then they are going to need those 
functions, or similar, to determine the ``cooked'' PC.

	Andrew

Re: parcelling up struct gdbarch

[Daniel Jacobowitz]

On Sat, Jul 14, 2001 at 11:16:32AM -0400, Andrew Cagney wrote:
> > undefined reference to `current_gdbarch'
> > undefined reference to `gdbarch_cannot_store_register'
> > undefined reference to `gdbarch_fp_regnum'
> > undefined reference to `gdbarch_npc_regnum'
> > undefined reference to `gdbarch_pc_regnum'
> > undefined reference to `gdbarch_register_byte'
> > undefined reference to `gdbarch_register_bytes'
> > undefined reference to `gdbarch_register_raw_size'
> > undefined reference to `gdbarch_sp_regnum'
> 
> 
> Live dangerously, try linking against libgdb.a :-)

Just for kicks, I tried it.  One file at a time, since I couldn't get
GNU ld to tell me what it was bringing in (is there an option for that?).

The problem is that gdbarch is all one file.  To resolve it, we have to
bring in gdbarch.o.  That brings in things like
legacy_breakpoint_from_pc, default_memory_insert_breakpoint, etc.  It
also brings in gdb_stdout, which means we need main.o.  It's hopeless.

This is, of course, resolvable.  We could build gdbarch.c as a large
number of separate files (or one file generating multiple objects, like
how libgcc2 is built) into an ar archive, gdbarch.a.  Then this
wouldn't happen.  I don't know if that's a good idea or not; what do
you think?

> >   REGISTER_BYTES, KERNEL_U_ADDR, PC_REGNUM, SP_REGNUM, FP_REGNUM
> 
> 
> REGISTER_BYTES is hard, I'll ignore it for the moment :-)

Such a pity :)  It's the one that really bugs me.

> KERNEL_U_ADDR lives in nm.h so that one is probably ok.
> 
> As for PC_REGNUM, NPC_REGNUM, ... SP_REGNUM and FP_REGNUM, I think we 
> need to study a little history.

> While it's taken 15 years to figure out, I think this is a register 
> model that works.  As far as core GDB is concerned PC_REGNUM, FP_REGNUM, 
> SP_REGNUM et.al. are all cooked registers.  While for many targets, 
> RAW_FP_REGNUM == COOKED_FP_REGNUM, might be true, they are separate.

> The gdbserver code that refers to those macros has, has a result of the 
> above revalation, become wrong.  The nat code, in general, should refer 
> to nat, raw or G register numbering and not cooked registers.  When it 
> comes to the registers to pass back with the T packet, I think it should 
> be given an explicit list.

It doesn't refer to those register numbers when generating a G packet
at all.  It just passes the entire buffer.  The only issue in creation
of G packets is REGISTER_BYTES.

It's the T packet that uses them, currently.  outreg() sends
regno:value pairs; regno is a cooked regno.  This is the only use of
REGISTER_BYTE or REGISTER_RAW_SIZE outside of a low-* file.

What would you say to providing this list in the form of (cooked regno,
raw offset, raw size) in the nm.h file?  It's very fragile, but without
protocol changes it's the best we can do right now.

I'm willing to do all sorts of intrusive things to gdbserver to work
around this for now; as I've said, that gdbserver built for two of the
targets I tried appears to be almost accidental.  I've no qualms about
breaking it on any number of other targets, if the fixes are cleaner
than the current state.

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

Re: parcelling up struct gdbarch

[H . J . Lu]

On Mon, Jul 16, 2001 at 11:25:36AM -0700, Daniel Jacobowitz wrote:
> 
> Just for kicks, I tried it.  One file at a time, since I couldn't get
> GNU ld to tell me what it was bringing in (is there an option for that?).
> 

# ld ... -Map map


H.J.

Re: parcelling up struct gdbarch

[Andrew Cagney]

> legacy_breakpoint_from_pc, default_memory_insert_breakpoint, etc.  It
> also brings in gdb_stdout, which means we need main.o.  It's hopeless.


If GDBserver is going to be come more tightly integrated into GDB then 
it is going to need to pick up some baggage like ui-file.


>> REGISTER_BYTES is hard, I'll ignore it for the moment :-)
> 
> 
> Such a pity :)  It's the one that really bugs me.


It is just a symptom of the below.



>> The gdbserver code that refers to those macros has, has a result of the 
>> above revalation, become wrong.  The nat code, in general, should refer 
>> to nat, raw or G register numbering and not cooked registers.  When it 
>> comes to the registers to pass back with the T packet, I think it should 
>> be given an explicit list.
> 
> 
> It doesn't refer to those register numbers when generating a G packet
> at all.  It just passes the entire buffer.  The only issue in creation
> of G packets is REGISTER_BYTES.


Hmm, by ``G packet registers'' I'm refering to how registers are laid 
out for a G packet.  When the stub creates a T packet that includes 
expedited registers, those registers should be identified using their 
G-packet numbering.


> It's the T packet that uses them, currently.  outreg() sends
> regno:value pairs; regno is a cooked regno.  This is the only use of
> REGISTER_BYTE or REGISTER_RAW_SIZE outside of a low-* file.


And it's wrong.

Per other e-mail, gdbserver can have either:

	o	*-nat.c map system registers onto
		raw register and then gdbserver
		map raw registers onto G-registers

	o	*-nat.c map system registers onto
		G-registers directly (when compiled
		for GDBSERVER, say).

The thing the *-nat and GDB server code shouldn't be doing is trying to 
map registers onto internal-to-GDB cooked registers.  (Keep in mind that 
the existing code base largely doesn't follow this :-( ).

Regardless, remote.c then has to map the incomming G-register onto the 
raw registers (as stored in regcache).


> What would you say to providing this list in the form of (cooked regno,
> raw offset, raw size) in the nm.h file?  It's very fragile, but without
> protocol changes it's the best we can do right now.


No, something completly outside of *.h that defines the G-packet layout 
(and possibly the register cache) and how *-nat.c should map registers 
onto it.


> I'm willing to do all sorts of intrusive things to gdbserver to work
> around this for now; as I've said, that gdbserver built for two of the
> targets I tried appears to be almost accidental.  I've no qualms about
> breaking it on any number of other targets, if the fixes are cleaner
> than the current state.


This won't (famous last words :-) break any targets and will help the 
task of multi-arching the MIPS.

Try building a few different MIPS targets and compare how the G-packet 
(unfortunatly aka raw register buffer) is structured for each - (almost) 
every single MIPS target has a different G-packet structure and they are 
not upward/downward compatible.

	Andrew

Re: parcelling up struct gdbarch

[J.T. Conklin]

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
>> legacy_breakpoint_from_pc, default_memory_insert_breakpoint, etc.  It
>> also brings in gdb_stdout, which means we need main.o.  It's hopeless.

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?  I expect and accept some baggage,
but at the moment I cannot comprehend why it would need high level
constructs like ui-file.

        --jtc

-- 
J.T. Conklin
RedBack Networks

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

Re: parcelling up struct gdbarch

[Daniel Jacobowitz]

On Mon, Jul 16, 2001 at 03:04:13PM -0400, Andrew Cagney wrote:
> 
> > legacy_breakpoint_from_pc, default_memory_insert_breakpoint, etc.  It
> > also brings in gdb_stdout, which means we need main.o.  It's hopeless.
> 
> 
> If GDBserver is going to be come more tightly integrated into GDB then 
> it is going to need to pick up some baggage like ui-file.

It's my opinion that that's the wrong way to do it.  We should
compartmentalize interface further away from the parts gdbserver needs. 
If necessary some functions can have separate minimal implementations
in gdbserver.

> >> The gdbserver code that refers to those macros has, has a result of the 
> >> above revalation, become wrong.  The nat code, in general, should refer 
> >> to nat, raw or G register numbering and not cooked registers.  When it 
> >> comes to the registers to pass back with the T packet, I think it should 
> >> be given an explicit list.
> > 
> > 
> > It doesn't refer to those register numbers when generating a G packet
> > at all.  It just passes the entire buffer.  The only issue in creation
> > of G packets is REGISTER_BYTES.
> 
> 
> Hmm, by ``G packet registers'' I'm refering to how registers are laid 
> out for a G packet.  When the stub creates a T packet that includes 
> expedited registers, those registers should be identified using their 
> G-packet numbering.

The definition of the remote protocol, such as it is, says:

   In general, the raw representation is determined by the
architecture, or GDB's interface to the architecture, while the virtual
representation can be chosen for GDB's convenience.  GDB's register
file, `registers', holds the register contents in raw format, and the
GDB remote protocol transmits register values in raw format.

The G packet is defined as the format of the register cache.

Are you saying you want to change that?  How do you envision doing this
without slaughtering the protocol?  That's where I'm confused.

> > It's the T packet that uses them, currently.  outreg() sends
> > regno:value pairs; regno is a cooked regno.  This is the only use of
> > REGISTER_BYTE or REGISTER_RAW_SIZE outside of a low-* file.
> 
> 
> And it's wrong.
> 
> Per other e-mail, gdbserver can have either:
> 
> 	o	*-nat.c map system registers onto
> 		raw register and then gdbserver
> 		map raw registers onto G-registers
> 
> 	o	*-nat.c map system registers onto
> 		G-registers directly (when compiled
> 		for GDBSERVER, say).
> 
> The thing the *-nat and GDB server code shouldn't be doing is trying to 
> map registers onto internal-to-GDB cooked registers.  (Keep in mind that 
> the existing code base largely doesn't follow this :-( ).

Largely?  I'd say completely.

> > What would you say to providing this list in the form of (cooked regno,
> > raw offset, raw size) in the nm.h file?  It's very fragile, but without
> > protocol changes it's the best we can do right now.
> 
> 
> No, something completly outside of *.h that defines the G-packet layout 
> (and possibly the register cache) and how *-nat.c should map registers 
> onto it.

I don't see the need for this profusion of register formats.  We've got
too many already.  Yes, the existing MIPS architectures all have
separate G packet formats; but what can be done about that, and what
needs to be?  GDB and gdbserver need to agree about this anyway,
because it also affects things like which registers can successfully be
set.

If anything, gdbserver should just be sending the registers in the same
format that *-nat.c gets them, and then they should pass through the
same conversion function.  I'm thinking gdb_gregset_t here and
REGISTER_U_ADDR here.  But again, I don't see what to do without
introducing a new packet type; and most architectures are not ready to
parse a gdb_gregset_t in a cross-debugger.

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

Re: parcelling up struct gdbarch

[Andrew Cagney]

> The definition of the remote protocol, such as it is, says:
> 
>    In general, the raw representation is determined by the
> architecture, or GDB's interface to the architecture, while the virtual
> representation can be chosen for GDB's convenience.  GDB's register
> file, `registers', holds the register contents in raw format, and the
> GDB remote protocol transmits register values in raw format.
> 
> The G packet is defined as the format of the register cache.
> 
> Are you saying you want to change that?  How do you envision doing this
> without slaughtering the protocol?  That's where I'm confused.


The documentation reflects the current state of play, good^D^D^D or^D^D 
bad.  If you alter the layout of the register cache, you change the 
remote protocol.  Hmm, something wrong here.


>> The thing the *-nat and GDB server code shouldn't be doing is trying to 
>> map registers onto internal-to-GDB cooked registers.  (Keep in mind that 
>> the existing code base largely doesn't follow this :-( ).
> 
> Largely?  I'd say completely.


remote-sim.h has a mapping mechanism - it needs to map between GDB's 
internal register layout and that of the simulator.

Originally GDB's register cache (and hence the G-packet) was defined by 
the layout of the raw register bytes returned by ptrace() fortunatly 
*-nat.c files are at least unpacking those structure and using 
supply_register() to fill the register cache.


>> No, something completly outside of *.h that defines the G-packet layout 
>> (and possibly the register cache) and how *-nat.c should map registers 
>> onto it.
> 
> 
> I don't see the need for this profusion of register formats.  We've got
> too many already.  Yes, the existing MIPS architectures all have


You've lost me here.  The reason for separating out and more formally 
specifying the G-packet layout is so that it is set in stone.  No matter 
what someone does to the register cache, or any other part of GDB, the 
remote protocol continues to work.

In the case of MIPS, this means that GDB will need to publish several 
different G-packets and support all of them.  Such is life, if long ago 
someone had thought to separate out and publish the G-packet layouts 
then we wouldn't be in this mess.

Regarding the register cache (or GDB's RAW registers).  A *-nat.c 
something needs to correctly map between raw registers (as stored in the 
register cache) and ptrace/... registers as supplied by the OS.  By 
formalizing the raw register layout, that process should be simplified. 
  (See posts from earlier this year).

> separate G packet formats; but what can be done about that, and what
> needs to be?  GDB and gdbserver need to agree about this anyway,
> because it also affects things like which registers can successfully be
> set.
> 
> If anything, gdbserver should just be sending the registers in the same
> format that *-nat.c gets them, and then they should pass through the
> same conversion function.  I'm thinking gdb_gregset_t here and
> REGISTER_U_ADDR here.  But again, I don't see what to do without
> introducing a new packet type; and most architectures are not ready to
> parse a gdb_gregset_t in a cross-debugger.


I think we're getting somewhere :-)

I take it you're proposing that G-packet layout would be defined by what 
was returned in the ptrace() buffer.  Don't forget that every OS has a 
different buffer layout - that means that they all have different 
G-packet layouts (I thought we already had too many).  This also means 
that you need to be very careful to not change anything that affects 
that packet for a given target.

It would give the layering:

   ptrace buffer
     |
   no-change (by gdbserver)
     |
   g register layout (including T registers)
     |
   remote.c uses some sort of unpack code
     |  (possibly in nat.c, this was always
     |   going to be needed and is clearly
     |   mising at present)
     |
   raw register layout
     .
     .

Remember that for the T and [Pp] packets to work, gdbserver will need to 
know something about that buffer.

	Andrew

Re: parcelling up struct gdbarch

[Daniel Jacobowitz]

On Mon, Jul 16, 2001 at 06:15:00PM -0400, Andrew Cagney wrote:
> The documentation reflects the current state of play, good^D^D^D or^D^D 
> bad.  If you alter the layout of the register cache, you change the 
> remote protocol.  Hmm, something wrong here.

OK, we're back to agreeing about everything.  That's good :)

> >> No, something completly outside of *.h that defines the G-packet layout 
> >> (and possibly the register cache) and how *-nat.c should map registers 
> >> onto it.
> > 
> > 
> > I don't see the need for this profusion of register formats.  We've got
> > too many already.  Yes, the existing MIPS architectures all have
> 
> 
> You've lost me here.  The reason for separating out and more formally 
> specifying the G-packet layout is so that it is set in stone.  No matter 
> what someone does to the register cache, or any other part of GDB, the 
> remote protocol continues to work.

I'm still with you.  This makes sense.

> In the case of MIPS, this means that GDB will need to publish several 
> different G-packets and support all of them.  Such is life, if long ago 
> someone had thought to separate out and publish the G-packet layouts 
> then we wouldn't be in this mess.

Right.  We don't have to worry currently about there being different
outgoing G's in gdbserver, but we do have to worry about incoming ones
in gdb from different remote stubs.  One thing at a time, though.

> > separate G packet formats; but what can be done about that, and what
> > needs to be?  GDB and gdbserver need to agree about this anyway,
> > because it also affects things like which registers can successfully be
> > set.
> > 
> > If anything, gdbserver should just be sending the registers in the same
> > format that *-nat.c gets them, and then they should pass through the
> > same conversion function.  I'm thinking gdb_gregset_t here and
> > REGISTER_U_ADDR here.  But again, I don't see what to do without
> > introducing a new packet type; and most architectures are not ready to
> > parse a gdb_gregset_t in a cross-debugger.
> 
> 
> I think we're getting somewhere :-)
> 
> I take it you're proposing that G-packet layout would be defined by what 
> was returned in the ptrace() buffer.  Don't forget that every OS has a 
> different buffer layout - that means that they all have different 
> G-packet layouts (I thought we already had too many).  This also means 
> that you need to be very careful to not change anything that affects 
> that packet for a given target.
> 
> It would give the layering:
> 
>    ptrace buffer
>      |
>    no-change (by gdbserver)
>      |
>    g register layout (including T registers)
>      |
>    remote.c uses some sort of unpack code
>      |  (possibly in nat.c, this was always
>      |   going to be needed and is clearly
>      |   mising at present)
>      |
>    raw register layout
>      .
>      .
> 
> Remember that for the T and [Pp] packets to work, gdbserver will need to 
> know something about that buffer.

I think that's acceptable.  The ptrace buffer meets some important
criteria:
 - it rarely changes, except perhaps to grow (SSE, altivec).
 - We already have to have code to parse it (in order for native gdb
   to work) although this code may not be easily cross-friendly

On the other hand, we've already GOT a de-facto format, and there are
debugging stubs out there that use it.  This is where I'm confused. 

What can we do to make it more obvious what format of G packet is being
sent?  My instinct tells me to define the format of the packet, with a
version number and architecture string, and define a message from
gdbserver to gdb which contains both arch and version.  This would be
useful for lots of other reasons too.  Then if we see a G packet after
receiving that version notification, we can just pass it off to the
appropriate handler and be done.

That same version notification can define a format for the T and P
packets also (of course gdbserver doesn't even support P packets yet,
as far as I see).

Rather than letting ideas continue to bounce around, how's this:
 - add an arch request to GDB and gdbserver.  It seems more natural for
gdbserver to send its architecture and gdb acknowledge if it
understands; but a qArch would work too.
 - Define, for a given gdbarch, how to parse the G/T/P packet register
numbering.

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

Re: parcelling up struct gdbarch

[Andrew Cagney]

> I think that's acceptable.  The ptrace buffer meets some important
> criteria:
>  - it rarely changes, except perhaps to grow (SSE, altivec).
>  - We already have to have code to parse it (in order for native gdb
>    to work) although this code may not be easily cross-friendly


See other e-mail about signals/events having similar problems.


> On the other hand, we've already GOT a de-facto format, and there are
> debugging stubs out there that use it.  This is where I'm confused. 


For MIPS we've defacto standards, lots of defacto standards :-)


> What can we do to make it more obvious what format of G packet is being
> sent?  My instinct tells me to define the format of the packet, with a
> version number and architecture string, and define a message from
> gdbserver to gdb which contains both arch and version.  This would be
> useful for lots of other reasons too.  Then if we see a G packet after
> receiving that version notification, we can just pass it off to the
> appropriate handler and be done.


There are two cases:

	o	GDB talking to one of those old stubs

	o	GDB talking to a not yet written stub

Even if someone did magic a new stub, GDB would still need to be able to 
talk to all the old stubs.  Consequently, I'll only look at old stubs.

With that in mind, I think, the G-packet <-> raw register mapping 
shouldn't be per gdbarch hard-coded but instead driven by something the 
user can specify on the command line.  Short term, some sort of 
hardwiring might be accepted.

Refering back to that figure:

   G-packet registers
     |
   raw registers
     |
   cooked registers

If raw registers are given names independant of the user visible cooked 
registers then, something as silly as:

	0:gpr0,4;1:gpr1,4;4;3:spr0;8;4;...

would even work.


> That same version notification can define a format for the T and P
> packets also (of course gdbserver doesn't even support P packets yet,
> as far as I see).


John S. Kallal submitted a patch: ``[PATCH] Add remote P packet ...'' 
It needed to be split in two (cleanup VS change) and along with a few 
other tweeks.

> Rather than letting ideas continue to bounce around, how's this:
>  - add an arch request to GDB and gdbserver.  It seems more natural for
> gdbserver to send its architecture and gdb acknowledge if it
> understands; but a qArch would work too.


See the multi-arch white paper.  It notes both alternatives. qArch is 
probably more inline with other parts of the protocol.  I don't think 
you need to do this to solve the current problems.

>  - Define, for a given gdbarch, how to parse the G/T/P packet register
> numbering.


As I noted above, a given gdbarch might have _several_ G-packet <-> raw 
register mappings

	Andrew

Re: parcelling up struct gdbarch

[Daniel Jacobowitz]

On Tue, Jul 17, 2001 at 01:46:48PM -0400, Andrew Cagney wrote:
> 
> > I think that's acceptable.  The ptrace buffer meets some important
> > criteria:
> >  - it rarely changes, except perhaps to grow (SSE, altivec).
> >  - We already have to have code to parse it (in order for native gdb
> >    to work) although this code may not be easily cross-friendly
> 
> 
> See other e-mail about signals/events having similar problems.

[I really need to think email out before I send it a little more, I
said the exact opposite of the above further down.  Oh well.]

> There are two cases:
> 
> 	o	GDB talking to one of those old stubs
> 
> 	o	GDB talking to a not yet written stub
> 
> Even if someone did magic a new stub, GDB would still need to be able to 
> talk to all the old stubs.  Consequently, I'll only look at old stubs.

Right.  Depending how this shapes out we may want a protocol extension
for new stubs to do it better, but that's not the issue here.

> With that in mind, I think, the G-packet <-> raw register mapping 
> shouldn't be per gdbarch hard-coded but instead driven by something the 
> user can specify on the command line.  Short term, some sort of 
> hardwiring might be accepted.
> 
> Refering back to that figure:
> 
>    G-packet registers
>      |
>    raw registers
>      |
>    cooked registers
> 
> If raw registers are given names independant of the user visible cooked 
> registers then, something as silly as:
> 
> 	0:gpr0,4;1:gpr1,4;4;3:spr0;8;4;...
> 
> would even work.

I don't understand why you say that we would need more than one
G-packet format per gdbarch.  Why?  Compatibility with different stubs? 
That seems like the wrong approach.  We've currently got one G-packet
format per definition of the register cache, and we've got one of those
per gdbarch, right?

I don't really understand what you mean by that string, either what the
fields or supposed to be or what it is supposed to define.

> John S. Kallal submitted a patch: ``[PATCH] Add remote P packet ...'' 
> It needed to be split in two (cleanup VS change) and along with a few 
> other tweeks.

OK, I see it.  The change will need to be completely redone after
whatever we decide for this, of course.

> > Rather than letting ideas continue to bounce around, how's this:
> >  - add an arch request to GDB and gdbserver.  It seems more natural for
> > gdbserver to send its architecture and gdb acknowledge if it
> > understands; but a qArch would work too.
> 
> 
> See the multi-arch white paper.  It notes both alternatives. qArch is 
> probably more inline with other parts of the protocol.  I don't think 
> you need to do this to solve the current problems.

I'm about to go read this more thoroughly.

Sure, we don't NEED it to solve this problem.  However, it would be a
logical extension at this point in time.  I'll address it separately.

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

Re: parcelling up struct gdbarch

[Andrew Cagney]

>> If raw registers are given names independant of the user visible cooked 
>> registers then, something as silly as:
>> 
>> 0:gpr0,4;1:gpr1,4;4;3:spr0;8;4;...
>> 
>> would even work.
> 
> 
> I don't understand why you say that we would need more than one
> G-packet format per gdbarch.  Why?  Compatibility with different stubs?


To remove the need to recompile GDB every time someone wants to get GDB 
to talk to a stub.  Instead of having to incorporate C code for each and 
every MIPS g-packet format, a simple generic table.  If the user finds 
their packet isn't included then just specify its layout on using the CLI.


> That seems like the wrong approach.  We've currently got one G-packet
> format per definition of the register cache, and we've got one of those
> per gdbarch, right?


Why should the entire register cache get re-structured everytime someone 
tweeks the architecture.  It is what GDB currently does, I don't think 
it is right.


> I don't really understand what you mean by that string, either what the
> fields or supposed to be or what it is supposed to define.


g-register 0 is 4 bytes and gets written to gpr0.
g-register 1 is 4 bytes and is written to gpr1
there is a gap of 4 bytes
g-register 3 is 8 bytes and is written to spr0
.
.
.

Re: parcelling up struct gdbarch

[Daniel Jacobowitz]

On Tue, Jul 17, 2001 at 02:36:53PM -0400, Andrew Cagney wrote:
> > I don't understand why you say that we would need more than one
> > G-packet format per gdbarch.  Why?  Compatibility with different stubs?
> 
> 
> To remove the need to recompile GDB every time someone wants to get GDB 
> to talk to a stub.  Instead of having to incorporate C code for each and 
> every MIPS g-packet format, a simple generic table.  If the user finds 
> their packet isn't included then just specify its layout on using the CLI.

> Why should the entire register cache get re-structured everytime someone 
> tweeks the architecture.  It is what GDB currently does, I don't think 
> it is right.

I'm looking right now at rs6000-tdep.c.  When we need a gdbarch for a
PPC binary, we call rs6000_gdbarch_init, which builds the architecture. 
What registers are available depends on what registers the target
architecture actually has.

At the same time, what registers gdbserver can provide are strictly
limited - in the same way that what registers infptrace can provide are
also strictly limited.  In this case, to the bulk of the GPRs, the
FPRs, and eventually (if no one beats me to it, I'll be adding kernel
support for...) the Altivec registers if we're on a processor that has
them.

No matter what architecture is set, if we're debugging userland Linux
applications, they see the same things.  Linux userland is, for all
intents and purposes that I can see, a gdbarch itself - two if you
break it up w.r.t. whether Altivec is available or not.  It determines
calling conventions and available registers.  This could, of course,
change.  It's not unreasonable to hypothesize ptrace returning
different registers depending on what processor is actually in use.

Somehow, we need to get GDB and gdbserver to agree on what registers
exist and what will be sent in a register info packet.  This will, as
far as I'm concerned, require some sort of protocol addition.  As I see
it:
  - gdbserver is the authority on what registers are available.
  - gdb must be prepared to give meaning to all of those registers
    (even if "meaning" == "none").
We can tie it to the gdbarch, but that seems like a bad idea,
especially given the flexibility with which gdbarches seem to be
generated.


So, in my N'th consecutive suggestion: is it reasonable to assign a
name to each register packet format, document them by name, and allow
GDB to send a query for the format which gdbserver will use?

(for what it's worth, which is probably not much, I like this solution
for this particular problem better than anything else I've come up with
or heard so far, and it sounds like we were both going in this general
direction.)

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

Re: parcelling up struct gdbarch

[Andrew Cagney]

> I'm looking right now at rs6000-tdep.c.  When we need a gdbarch for a
> PPC binary, we call rs6000_gdbarch_init, which builds the architecture. 
> What registers are available depends on what registers the target
> architecture actually has.


Careful.  That code is now interpreted in a different light.

GDBarch sets up a mapping between an user-visible or cooked registers 
and the raw register cache.  Which registers are ``available'' depends 
on several things:

	o	the cooked registers visible to
		the user

	o	the raw registers stored in the register cache

	o	the register values supplied by the
		target (or gdbserver).


> At the same time, what registers gdbserver can provide are strictly
> limited - in the same way that what registers infptrace can provide are
> also strictly limited.  In this case, to the bulk of the GPRs, the
> FPRs, and eventually (if no one beats me to it, I'll be adding kernel
> support for...) the Altivec registers if we're on a processor that has
> them.
> 
> No matter what architecture is set, if we're debugging userland Linux
> applications, they see the same things.  Linux userland is, for all
> intents and purposes that I can see, a gdbarch itself - two if you
> break it up w.r.t. whether Altivec is available or not.  It determines
> calling conventions and available registers.  This could, of course,
> change.  It's not unreasonable to hypothesize ptrace returning
> different registers depending on what processor is actually in use.


Don't forget you need to bump the syscall number as part of that new 
interface.


> Somehow, we need to get GDB and gdbserver to agree on what registers
> exist and what will be sent in a register info packet.  This will, as
> far as I'm concerned, require some sort of protocol addition.  As I see
> it:
>   - gdbserver is the authority on what registers are available.
>   - gdb must be prepared to give meaning to all of those registers
>     (even if "meaning" == "none").
> We can tie it to the gdbarch, but that seems like a bad idea,
> especially given the flexibility with which gdbarches seem to be
> generated.


Either that or a formal specification of what a G packet should contain 
and then stick too it.


> So, in my N'th consecutive suggestion: is it reasonable to assign a
> name to each register packet format, document them by name, and allow
> GDB to send a query for the format which gdbserver will use?


Hmm


> (for what it's worth, which is probably not much, I like this solution
> for this particular problem better than anything else I've come up with
> or heard so far, and it sounds like we were both going in this general
> direction.)


I think there are two paths.  One has a formalized G packet layout the 
other has  total flexability.  If GDB is going to try to accept multiple 
different packet layouts then it will surely miss one.  In that case, 
why not assume it will miss one and give the user the flexability to 
specify a custom packet spec.  The set of named packets could just be 
pre-defined specifications.  A set of hard-wired packet specs would be a 
compromise.

	Andrew

Re: parcelling up struct gdbarch

[Daniel Jacobowitz]

On Thu, Jul 19, 2001 at 01:52:58AM -0400, Andrew Cagney wrote:
> > No matter what architecture is set, if we're debugging userland Linux
> > applications, they see the same things.  Linux userland is, for all
> > intents and purposes that I can see, a gdbarch itself - two if you
> > break it up w.r.t. whether Altivec is available or not.  It determines
> > calling conventions and available registers.  This could, of course,
> > change.  It's not unreasonable to hypothesize ptrace returning
> > different registers depending on what processor is actually in use.
> 
> 
> Don't forget you need to bump the syscall number as part of that new 
> interface.

Well, the example I was considering here was something like SSE
registers or Altivec registers which may or may not be available - you
can safely increase the size of the user struct, and you can add
subrequests like PTRACE_GETFPXREGS (or whatever it's called).

> > So, in my N'th consecutive suggestion: is it reasonable to assign a
> > name to each register packet format, document them by name, and allow
> > GDB to send a query for the format which gdbserver will use?
> 
> 
> Hmm
> 
> 
> > (for what it's worth, which is probably not much, I like this solution
> > for this particular problem better than anything else I've come up with
> > or heard so far, and it sounds like we were both going in this general
> > direction.)
> 
> 
> I think there are two paths.  One has a formalized G packet layout the 
> other has  total flexability.  If GDB is going to try to accept multiple 
> different packet layouts then it will surely miss one.  In that case, 
> why not assume it will miss one and give the user the flexability to 
> specify a custom packet spec.  The set of named packets could just be 
> pre-defined specifications.  A set of hard-wired packet specs would be a 
> compromise.

Well, implementation-wise and protocol-wise I'll need the same things
to do it hard-wired before I can do it flexibly, so I'm implementing
that structure now (I'm mostly done it, actually - I'm testing it for
mips32 now, and if it works I'll post it in the morning).

Having flexible packet specs would remove a couple of trivial functions
that I wrote, but I'd prefer to tackle that idea after the remainder of
the issues have been dealt with.

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

Re: parcelling up struct gdbarch

[Daniel Jacobowitz]

On Wed, Jul 18, 2001 at 11:22:42PM -0700, Daniel Jacobowitz wrote:
> Well, implementation-wise and protocol-wise I'll need the same things
> to do it hard-wired before I can do it flexibly, so I'm implementing
> that structure now (I'm mostly done it, actually - I'm testing it for
> mips32 now, and if it works I'll post it in the morning).
> 
> Having flexible packet specs would remove a couple of trivial functions
> that I wrote, but I'd prefer to tackle that idea after the remainder of
> the issues have been dealt with.

And it works.  I currently move handling of the 'g' and 'G' packets off
into the low-* file, which makes drastically more sense anyway.  The
code for prepare_resume_reply still needs to be handled, but the
changes are trivial once the rest is in place.

In remote.c, I add a 'qRegisters' packet with the reply
'qRegisters:IDENTIFIER', where IDENTIFIER is a (hex-encoded) defined
name.  It defines a register numbering, which remote.c takes care to
use when talking to the target if one is available.  The client-side
changes are finished and I'll post them in the morning when I'm awake
enough to write a proper changelog.

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

Re: parcelling up struct gdbarch

[Andrew Cagney]

> 
> And it works.  I currently move handling of the 'g' and 'G' packets off
> into the low-* file, which makes drastically more sense anyway.  The
> code for prepare_resume_reply still needs to be handled, but the
> changes are trivial once the rest is in place.


I'm sure it will work.


> In remote.c, I add a 'qRegisters' packet with the reply
> 'qRegisters:IDENTIFIER', where IDENTIFIER is a (hex-encoded) defined
> name.  It defines a register numbering, which remote.c takes care to
> use when talking to the target if one is available.  The client-side
> changes are finished and I'll post them in the morning when I'm awake
> enough to write a proper changelog.


Just a heads up.  This ``IDENTIFIER'' has consequences. The mechanics 
are the easy bit.  It is sorting out things like how to consitently 
define ``IDENTIFER'' that isn't.

	Andrew

Re: parcelling up struct gdbarch

[Andrew Cagney]

>> Don't forget you need to bump the syscall number as part of that new 
>> interface.
> 
> 
> Well, the example I was considering here was something like SSE
> registers or Altivec registers which may or may not be available - you
> can safely increase the size of the user struct, and you can add
> subrequests like PTRACE_GETFPXREGS (or whatever it's called).


Well, if you're not careful all existing GDB binaries will mysteriously 
barf.

	Andrew

Re: parcelling up struct gdbarch

[Andrew Cagney]

Daniel,

Somewhere in this really long thread you suggested moving the code that 
mapped:

	<target signal>
   <->	gdb signal (aka enum target_signal ulgh!)

out of target.[hc] and into its own file.

Yes, this sounds like a good idea regardless.  A layer (*-nat.c) in the 
target stack _uses_ the mapping.  It isn't part of the mapping.

One day GDB might learn to handle multiple mappings but for the moment 
just one hard-wired mapping is working pretty good.

	Andrew