Re: RFC: Change to gdb/README

["Eli Zaretskii" <eliz@is.elta.co.il>]

> Date: Fri, 15 Dec 2000 20:47:36 +0000
> From: Fernando Nasser <fnasser@cygnus.com>
> 
> It will be much easier if people build in a separate directory.
> 
> Is it OK to change the instructions in the gdb/README file to
> somewhat favor that choice?

I think it is a good idea, but I would suggest to say a couple of
words _why_ this is the recommended alternative.  Otherwise, the
following text:

> You can build GDB right in the source directory:
> 
>         cd gdb-5.0
>         ./configure
>         make
>         cp gdb/gdb /usr/local/bin/gdb   (or wherever you want)
> 
> However, we recommend that an empty directory be used instead:

Leaves the naive reader wondering why one way is recommended more than
the other.
From jtc@redback.com Fri Dec 15 14:56:00 2000
From: jtc@redback.com (J.T. Conklin)
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: additional vector function to improve  register fetch performance
Date: Fri, 15 Dec 2000 14:56:00 -0000
Message-id: <5mae9xs391.fsf@jtc.redback.com>
References: <5m3dfzj2qs.fsf@jtc.redback.com> <3A396A70.20519EF8@cygnus.com>
X-SW-Source: 2000-12/msg00107.html
Content-length: 3387

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
>> Might be changed to:
>> 
>> prefetch_sp ();
>> prefetch_fp ();
>> prefetch_pc ();
>> prefetch_register (R0_REGNUM);
>> sp = read_sp ();
>> fp = read_fp ();
>> pc = read_pc ();
>> r0 = read_register (R0_REGNUM);
>> 
>> (I'm assuming the prefetch* functions are added to regcache.c to do
>> whatever housekeeping is required and call the target vector
>> function).

Andrew> To follow on from Stephane's comments.  I have a feeling that
Andrew> this would make things unnecessarily complicated.
Andrew>
Andrew> Looking at the remote case and the ``T'' packet.  There isn't
Andrew> any reason why the ``T'' packet doesn't just return all of the
Andrew> registers.  Across a TCP connection that should have zero
Andrew> marginal cost.

Note that while I primarily use the remote protocol, I am looking at
this issue of register fetch performance more generically.

The problem is that the upper layer of GDB do not communicate with the
target layer in such that a target that can perform different types of
register fetches can select the optimum one.  

This is not an issue if the target can only fetch the entire register
set.  But I think it is desirable if a target can fetch a subset of
registers so that GDB would take advantage of that ability.

Imagine a processor with 32 4-byte integer registers, 32 4-byte float-
ing point registers, and a handful of control and other miscellaneous
registers.  If registers are ascii-hex encoded, the register data will
be ~1K bytes.  On a 9600bps link, assuming no other overhead, it will
takes over one second to receive.  If there was some way to fetch only
the registers that were needed, we'd be able to significantly improve
that time.  Even if the protocol is only able to fetch a single register,
assuming "reasonable" command latency GDB might be able to issue multiple
fetch register commands in less time.

The reason I suggested a cache model is that caches and prefetching
are already well understood concepts.  

Andrew> The other thing to consider is given a request for reg N, the
Andrew> target could satisfy it by fetching an entire block of
Andrew> registers M<=N<=O and entering them all into the cache.

How are M and O selected?  A target specific back end has knowledge
about the target and can select an appropriate block: Wind River's WDB
breaks things into integer registers, floating point registers,
control registers, etc. which works quite well in practice.  But I
don't know how something similar could be done with a generic target 
like remote.c

Andrew> In away the ``G'' (registers) packet does this - you ask for
Andrew> one register and get back a block.  Unfortunatly the block is
Andrew> very very large and fixed.

Agreed.  And as long as the remote protocol only requests full packets,
performance is reasonable.  But if you added support for a fetch single
register command to complement the existing store single register 
command, I think you would find that performance would suffer because 
GDB would fetch multiple single registers when a single register fetch 
would be optimal.  Today can see the same with single register stores in
some circumstances.  

I think we could recommend that single register stores only be
implemented for those targets where DECR_PC_AFTER_BREAK != 0.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From micrio@mv.com Fri Dec 15 17:36:00 2000
From: "Peter Reilley" <micrio@mv.com>
To: "gdb mailing list" <gdb@sources.redhat.com>
Cc: "Jim McGreggor" <jamesm@macraigor.com>
Subject: Re: GDB with Macraigors Raven
Date: Fri, 15 Dec 2000 17:36:00 -0000
Message-id: <001401c06700$888ae9c0$05d145cc@ppro>
X-SW-Source: 2000-12/msg00108.html
Content-length: 706

Yes, it is compatible with the Raven but you must get it from
the www.ocdemon.com site.   GDB has been modified and
the changes have not been put in the main source tree yet.
If you are running on Linux then there are libraries and a driver
required.   If you are running on Windows then a dll is required.

Pete.


-----Original Message-----
From: brenner <joel.brenner@tchip.ch>
To: gdb mailing list <gdb@sources.redhat.com>
Date: Friday, December 15, 2000 10:01 AM
Subject: GDB with Macraigors Raven


>Is GDB 5.0 compatible with RAVEN Jtag module or Jenni from EPI?? If yes
>wath are the configuratio options?
>(at the moment I've installed GDB 5.0 but there arent target like OCD)
>
>Tanks Brenner
>