From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fernando Nasser To: Andrew Cagney Cc: "Peter.Schauer" , gdb-patches@sourceware.cygnus.com Subject: Re: Hopefully my last request for 5.0 incorporation Date: Fri, 14 Apr 2000 06:54:00 -0000 Message-id: <38F721D0.4CFF03E8@redhat.com> References: <200004131903.VAA10696@reglos.regent.e-technik.tu-muenchen.de> <38F66D15.A68BBB52@cygnus.com> X-SW-Source: 2000-04/msg00287.html For sake of reference by the others I will repeat here what is being proposed. 1) Have "i r" stand for "info reg". This used to work before but the addition of a new (much less frequently used) info command that also starts with "r" ("info remote-process") made it ambiguous. "i r" is so much used that I am in favor of adding this one. As I heard nothing to the contrary I will add it to gdb5. 2) Have "maint i" stand for "maint info". This also worked before but the addition of "maint internal-error" it does not work anymore. I am quite concerned about adding alias that are so short. However, "i" is an alias for the "info" command, and this is a very strong argument in favor of making it an alias for "info" under "maintenance". After all "maintenance" is just a prefix that help us separate our "internal use only" (TM) commands from the normal user commands. So, in this one exceptional case, due to the long term acceptance of "i" as short for "info", I will incorporate it. But please folks, no more cryptic abrevs pls. ;-) -- 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 jingham@cygnus.com Fri Apr 14 08:53:00 2000 From: James Ingham To: Jonathan Larmour Cc: James Ingham , Andrew Cagney , insight@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: Insight remote output doesn't output to console window immediately Date: Fri, 14 Apr 2000 08:53:00 -0000 Message-id: <14583.16305.343648.795283@leda.cygnus.com> References: <38F6404E.5959A4E0@redhat.co.uk> <38F65D4D.8B390EFA@cygnus.com> <38F67617.D1A2A6B3@redhat.co.uk> <14582.31502.754152.913822@leda.cygnus.com> <38F6873A.8284A61B@redhat.co.uk> X-SW-Source: 2000-04/msg00288.html Content-length: 765 Jonathan, > James Ingham wrote: > > > > Okay, check this in. > > Trunk, branch or both? Both. Maybe add a FIXME to the comment, since I often grep for FIXME when I am trying to figure out what I should do next (though as I said, this one is already on the short list.) > > > As for the Changelog-gdbtk's. They should be changed to just > > ChangeLog - the gdbtk is historic; the C-code files used to live at > > the top level, but since Insight couldn't be included in the FSF gdb > > releases, we had to have separate ChangeLogs... > > Would you like me to rename those two then? Obviously not forgetting to > remove all the change-log-default-name emacs variables. That would be trunk > only of course. That would be lovely, thanks. Jim >From ezannoni@cygnus.com Fri Apr 14 09:17:00 2000 From: Elena Zannoni To: jimb@cygnus.com, gdb-patches@sourceware.cygnus.com Subject: [WITHDRAW PATCH] cleanup section_addr_info struct Date: Fri, 14 Apr 2000 09:17:00 -0000 Message-id: <14583.17571.879578.797464@kwikemart.cygnus.com> X-SW-Source: 2000-04/msg00289.html Content-length: 133 Disregard the following patch: http://sourceware.cygnus.com/ml/gdb-patches/2000-04/msg00280.html I'll submit a new one ASAP. Elena >From taylor@cygnus.com Fri Apr 14 09:34:00 2000 From: David Taylor To: Jim Blandy Cc: gdb-patches@sourceware.cygnus.com, Jeff Law Subject: Re: RFA: distinguish between pointers and addresses Date: Fri, 14 Apr 2000 09:34:00 -0000 Message-id: <200004141633.MAA15832@texas.cygnus.com> X-SW-Source: 2000-04/msg00290.html Content-length: 875 From: Jim Blandy Date: Mon, 10 Apr 2000 15:22:35 -0500 (EST) The following patch needs approval from: - David Taylor (the bulk of it) Approved. - Andrew Cagney (new gdbarch entries) - Michael Snyder (tracepoint.c changes) - Jeff Law (hppa-tdep.c changes) - Eli Zaretskii (doc changes) [...] This patch allows GDB to cope with machines where pointers are not simply byte addresses. For example, some machines with small word sizes use word addresses for code pointers, to steal a few more address bits. The D10V is such a processor; I think this patch makes it possible to replace all those ugly GDB_TARGET_IS_D10V conditionals in GDB's architecture-independent code with functions nicely isolated in d10v-tdep.c. Such a clean up would be a good thing.