From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Eli Zaretskii" To: fnasser@cygnus.com Cc: gdb@sources.redhat.com Subject: Re: RFC: Change to gdb/README Date: Fri, 15 Dec 2000 14:42:00 -0000 Message-id: <4839-Sat16Dec2000004058+0200-eliz@is.elta.co.il> References: <3A3A8368.1AB607D@cygnus.com> X-SW-Source: 2000-12/msg00106.html > Date: Fri, 15 Dec 2000 20:47:36 +0000 > From: Fernando Nasser > > 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 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 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" To: "gdb mailing list" Cc: "Jim McGreggor" 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 To: gdb mailing list 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 >