From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fernando Nasser To: jtc@redback.com Cc: gdb@sourceware.cygnus.com, Andrew Cagney , taruna@redhat.com, Eric Bachalo Subject: Re: Remote protocol extension for register ranges Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38D921AC.A133F89D@redhat.com> References: <38D8CFA4.C3535C93@redhat.com> <5m66ufj7ii.fsf@jtc.redbacknetworks.com> X-SW-Source: 2000-q1/msg00773.html "J.T. Conklin" wrote: > > >>>>> "Fernando" == Fernando Nasser writes: > Fernando> Presently, the remote protocol can only read all registers > Fernando> of a target. This is OK for the context registers (the ones > Fernando> that are saved by the OD on a context switch) but this is a > Fernando> serious limitation for machines that have lots of additional > Fernando> registers. It is just not feasible to read them all at > Fernando> every "g" packet. > > If a target has so many registers that you don't want to read them all > with the "g" command packet, I believe you are going to need something > similar for the "G" command packet. Otherwise, any read/modify/write > operations GDB does will end up reading and writing the entire set. > I agree. But as you say below, the G packet is a little more complex and we have the P packet already. I was planning on using P for writes. > Fernando> I would like to add parameters to the "g" packet. Something > Fernando> similar has been proposed before -- the only difference is > Fernando> that I would like the parameters to be a register number or > Fernando> a register number range range. > > You could probably get away with adding parameters to the "g" command > packet --- as far as I can tell none of the sample stubs completely > parse the command. But if GDB sent "g" command packet containing a > register range to such stubs, it would get the entire register set. > You would have to write a some sort of run time test to determine > whether it handled register ranges. > Yes, the run time test (as it is done for P packets) is the idea. > Adding parameters to the "G" command packet is more troublesome --- > the register values immediately follow the command character. > I was thinking of using 'P'... > For these reasons, I recommend implementing a new set of commands > which would deprecate G/g/P/p. > > Perhaps something like: > > Get Registers: > y, > > Set Registers: > Y,, > This may be a nice option, and I would not discard it for the future (although I am not sure how I would use it from gdb without mixing some different levels of information). I am just planning on making a very small change to gdb and one of the stubs so the registers can be shown. I don't think I will be given much time to do that so I have to keep it very simple. That is why I would still rather do the 'g' extension (for now) to be able to work with register numbers (while an eventual "yY" would work with byte offsets). Note that this does not precludes the implementation of "yY" later, as they have different parameter types (regno's and offsets). And we extend the existing command with the current type of arguments while the new ones, when implemented, will have a different type. > But while we are adding commands, we might want to consider whether > there are any other arguments we should add. > > One that comes to mind is a thread-id. Currently, when we want to get > the registers from several threads on the target, GDB has to issue a > set thread command before each store/fetch register command. If the > thread-id was part of the request, it could significantly improve > remote protocol performance, especially on low-bandwidth and/or high > latency connections. > This looks like a time saving operation. But other people that are doing threads work will know better than me. We can eventually add "t=NNNN,". Its acceptance can be tested at run time like the other optimizations/extensions. -- Fernando Nasser Red Hat, Inc. - Toronto E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311 Toronto, Ontario M4P 2C9 Fax: 416-482-6299 >From eliz@delorie.com Sat Apr 01 00:00:00 2000 From: Eli Zaretskii To: gdb@sourceware.cygnus.com Subject: Problems with "make install" Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003191226.HAA08370@indy.delorie.com> X-SW-Source: 2000-q1/msg00738.html Content-length: 1424 I'm testing the "make install" targets, and I see several problems which look like bugs. 1) gdb/Makefile doesn't seem to run mkinstalldirs to create some of the directories, such as ${prefix}/bin and ${prefix}/man. Similarly, gdb/doc/Makefile doesn't create ${prefix}/info and ${prefix}/html. Why is that? 2) Why doesn't "make install" install the Info docs? For that matter, why doesn't "make" doesn't "make info"? One needs to say "make info" and "make install-info" to get them, which is different from all the other GNU project I've seen. 3) The top-level Makefile.in says this: INSTALL = $(SHELL) $$s/install-sh -c This unconditionally forces Make to use the install-sh script for installation, including in all the subdirectories. Why is this necessary? Is it possible to replace this with the usual Autoconf magic that finds the install program at configure time? (All the subdirectories already do that, but the results of those tests are overridden by the above.) My problem with this is that install-sh is truncated to "install-" on 8+3 filesystems, and Make then doesn't think it's necessary to run the commands for targets like install-recursive because it thinks that install-recursive is a file which already exists. So the DJGPP configuration script renames install-sh to a different name, which then fails because of the above. Using the normal install program would solve all that nuisance. >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: Eli Zaretskii Cc: gdb@sourceware.cygnus.com Subject: Re: Dependence on config.status Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38BCCA84.74A4143E@cygnus.com> References: <200002280657.BAA27090@indy.delorie.com> X-SW-Source: 2000-q1/msg00464.html Content-length: 814 Eli Zaretskii wrote: > > defs_h in gdb/Makefile includes config.status. This makes all of the > GDB sources depend on it. The result is that each time I reconfigure > the package, everything gets recompiled, which is quite annoying when > working on some minor configury buglets. I guess you're refering to things like Makefile problems. > Why does GDB need to be dependent on config.status, in addition to > config.h? I don't know and yes I agree with you. I think it is just history. Grubbing through really old versions of gdb I've found that defs_h was added on: date: 1993/06/23 22:59:13; author: rich and it included config.status from day one. The addition of config.h is far more recent: date: 1996/03/17 00:35:57; author: fnf Assuming no one objects, I'll delete it in the morning. Andrew >From law@cygnus.com Sat Apr 01 00:00:00 2000 From: Jeffrey A Law To: guo@cup.hp.com Cc: gdb@sourceware.cygnus.com Subject: Re: hppa 10.20 test result comparison Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <20487.953919445@upchuck> References: <200003232040.MAA14957@cygnus.com> X-SW-Source: 2000-q1/msg00798.html Content-length: 633 In message <200003232040.MAA14957@cygnus.com>you write: > This is a comparison of 2/4's gdb and 3/21's. The sourceware version of > 3/21 has disabled elf32-hppa support in bfd, so there's no hpux 11.00 > comparison for the sourceware version. elf32-hppa is unsupported and nobody should be using it. It is unlikely elf32-hppa will ever be supported again. For hpux11.00 in 32bit mode you should still be using SOM, so I don't see why you can't do an hpux11.00 comparison for the sourceware version. Support for hpux11.00 64bit mode will be contributed once we get final acceptance on the PA64 toolchain from HP. jeff