From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fernando Nasser To: Daniel Berlin Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH]: add set/show debug, move gdb debugging flags into it Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38CD37F8.D1B20C40@cygnus.com> References: X-SW-Source: 2000-q1/msg00673.html Daniel, Your patch is something we've been looking forward to. In the perspective of the CLI (which I am the maintainer) I am eager to see it checked in. It touches other files though, so I would rather wait for Andrew to see them overnight (his day). However... your patch is removing the old command formats. I have not yet checked in David Whedon patch for deprecating commands (I've been *real* busy these days) so we can't use it yet. This leaves us with two choices: we wait a week or so and use David deprecating thing, or just leave the old commands alive for now. In either case you would have to adjust your patch, I hope you don't mind. Thank you very much for doing this. This "set xyxsdert$#@%$debug" commands were really weird. Best regards, Fernando Daniel Berlin wrote: > > Attached is a patch to add "set debug" and "show debug", and move the gdb > debugging stuff (targetdebug,expressiondebug,etc) into those lists. > > I renamed targetdebug,expressiondebug,etc (all the debug settings i > moved), to remove the "debug" from their name, so you do "set debug target > 1" rather than "set debug targetdebug 1". > > The new command lists are named setdebuglist/showdebuglist, and are in > command.c. > I put set_debug and show_debug into command.c, for lack of a better place. > The point of all this is to make it much easier to see what debugging > flags you can set for GDB, and what they were set to. It also declutters > the set list. > I also enabled monitordebug, since it said int he comment it was waiting > for "set debug". > > I have no idea who needs to approve this, since it touches a bunch of > stuff, but is only related to one domain so to speak. > > I'm working on a changelog entry, i wanted to get comments first. > > Example of what you get with the patch installed: > (gdb) help set debug > Generic command for setting gdb debugging flags > List of set debug subcommands: > set debug arch -- Set architecture debugging > set debug event -- Set event debugging > set debug expression -- Set expression debugging > set debug remote -- Set debugging of remote protocol > set debug serial -- Set serial debugging > set debug target -- Set target debugging > set debug varobj -- Set varobj debugging > Type "help set debug" followed by set debug subcommand name for full > documentation. > Command name abbreviations are allowed if unambiguous. > (gdb) > > (gdb) help show debug > Generic command for showing gdb debugging flags > List of show debug subcommands: > show debug arch -- Show architecture debugging > show debug event -- Show event debugging > show debug expression -- Show expression debugging > show debug remote -- Show debugging of remote protocol > show debug serial -- Show serial debugging > show debug target -- Show target debugging > show debug varobj -- Show varobj debugging > Type "help show debug" followed by show debug subcommand name for full > documenta > tion. > Command name abbreviations are allowed if unambiguous. > (gdb) > (gdb) show debug > arch: Architecture debugging is 0. > event: Event debugging is 0. > expression: Expression debugging is 0. > remote: Debugging of remote protocol is 0. > serial: Serial debugging is 0. > target: Target debugging is 0. > varobj: Varobj debugging is 0. > (gdb) set debug > "set debug" must be followed by the name of a print subcommand. > List of set debug subcommands: > set debug arch -- Set architecture debugging > set debug event -- Set event debugging > set debug expression -- Set expression debugging > set debug remote -- Set debugging of remote protocol > set debug serial -- Set serial debugging > set debug target -- Set target debugging > set debug varobj -- Set varobj debugging > Type "help set debug" followed by set debug subcommand name for full > documentati > on. > Command name abbreviations are allowed if unambiguous. > (gdb) > > ------------------------------------------------------------------------------------------------------------------------ > Name: setdebug.diff > setdebug.diff Type: Plain Text (TEXT/PLAIN) > Encoding: BASE64 -- Fernando Nasser Red Hat - Toronto E-Mail: fnasser@cygnus.com 2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311 Toronto, Ontario M4P 2C9 Fax: 416-482-6299 >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: Jim Kingdon Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [RFC] Notes on QUIT and STREQ et.al. Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38CD7F9E.206D9351@cygnus.com> References: <200003131412.PAA16094@landau.wins.uva.nl> X-SW-Source: 2000-q1/msg00678.html Content-length: 938 Jim Kingdon wrote: > > I'm not sure if we want STREQ to go. I think that `STREQ (a, b)' is > > both easier to read and easier to type than `strcmp (a, b) == 0'. > > Well, perhaps it is because I have gotten used to the strcmp == 0 > idiom, but I find it to be pretty annoying to have to look up a macro > like this (sure, it _probably_ is defined in the obvious way, but you > don't know that for sure when digging into a new program). Granted > strcmp == 0 is hard to understand until/unless you know the standard C > library well enough for it to be second nature. Well I personally prefer the forms: strcmp() == 0 (read: strcmp () equal) and strcmp() != 0 (read: strcmp () not-equal) over ``strcmp()'' and ``!strcmp()'' as they offer a queue to the programer but even then that style isn't a requirement. Like you, the one I don't trust is STREQ(). I'm never 100% certain what that macro is doing behind my back :-) Andrew >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: GDB Patches Subject: Please ``withdraw'' patches Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38BB29FF.2467FCE@cygnus.com> X-SW-Source: 2000-q1/msg00410.html Content-length: 449 Hello, I've just spent an hour going over a patch (yes I'm working through a long backlog) only to then find a later submission by the same author supersedes the earlier posting. If people withdraw or re-submit patches, could they please to a follow up to the original posting making it clear that that submission was withdrawn. enjoy, Andrew (Hopefully a patch tracking system will help with this problem (although it may not eliminate it)) >From fnasser@cygnus.com Sat Apr 01 00:00:00 2000 From: Fernando Nasser To: glen mccready Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [RFA] gdb/command.c, gdb/command.h: "help all" Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38DBB714.67024F64@cygnus.com> References: <200003241731.JAA12735@cygint.cygnus.com> <8bg9c0$3rt$1@cronkite.cygnus.com> X-SW-Source: 2000-q1/msg00991.html Content-length: 1267 glen mccready wrote: > > I will get better at this, I'm sure. :-/ > That is fine. There are lots of common practices that are not written anywhere, so you post and we tell you. After a short while you'll know them all and will be your turn to tell others... > In article < 200003241731.JAA12735@cygint.cygnus.com >, > glen mccready wrote: > [...] > >Fri Mar 24 12:10:38 2000 glen mccready > > > > * commands.c (help_all): Add functionality to display a complete > > listing of available commands. > > Fri Mar 24 12:10:38 2000 glen mccready > > * command.c, command.h (help_all): Add functionality to display > a complete listing of available commands. Better yet: Fri Mar 24 12:10:38 2000 glen mccready * command.c (help_all): New function. Add functionality to display a complete listing of available commands. * command.h: Add declaration for the above. If nobody objects by the end of the afternoon, please check it in. -- Fernando Nasser Red Hat - Toronto E-Mail: fnasser@cygnus.com 2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311 Toronto, Ontario M4P 2C9 Fax: 416-482-6299 >From fnasser@cygnus.com Sat Apr 01 00:00:00 2000 From: Fernando Nasser To: gdb-patches@sourceware.cygnus.com, James Ingham Subject: RFC: Patch to make "set remotebaud" and "-b" work for RDI targets Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <3873D9FC.EF374435@cygnus.com> X-SW-Source: 2000-q1/msg00012.html Content-length: 1412 The baud specified on the target command itself takes precedence, but if it has not been specified and gdb was invoked with a "-b" argument or the user (or Insight) have issued a "set remotebaud" command, that valued is tried (comapared against the list of valid values kept by the rdi code). -- Fernando Nasser Cygnus Solutions - Toronto Office E-Mail: fnasser@cygnus.com 2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311 Toronto, Ontario M4P 2C9 Fax: 416-482-6299 Index: rdi-share/serdrv.c =================================================================== RCS file: /cvs/cvsfiles/devo/gdb/rdi-share/serdrv.c,v retrieving revision 1.4 diff -c -r1.4 serdrv.c *** serdrv.c 1999/01/28 03:50:16 1.4 --- serdrv.c 2000/01/05 23:45:25 *************** *** 32,37 **** --- 32,39 ---- #include "params.h" #include "logging.h" + extern int baud_rate; /* From gdb/top.c */ + #ifdef COMPILING_ON_WINDOWS # undef ERROR # undef IGNORE *************** *** 228,233 **** --- 230,241 ---- else printf( "could not understand baud rate %s\n", arg ); #endif + } + else if (baud_rate > 0) + { + /* If the user specified a baud rate on the command line "-b" or via + the "set remotebaud" command then try to use that one */ + process_baud_rate( baud_rate ); } #ifdef COMPILING_ON_WINDOWS >From jlarmour@redhat.co.uk Sat Apr 01 00:00:00 2000 From: Jonathan Larmour To: fnasser@redhat.com, gdb-patches@sourceware.cygnus.com Subject: Re: thumb_skip_prologue too adventurous Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38D40052.AF731E81@redhat.co.uk> References: <38D3FFC8.32082A85@redhat.co.uk> X-SW-Source: 2000-q1/msg00770.html Content-length: 1896 Jonathan Larmour wrote: > 2000-03-18 Jonathan Larmour > > * arm-tdep.c (thumb_skip_prologue): Take function end addr argument > so that we can stop searching for the prologue past the function end > (arm_skip_prologue): Call thumb_skip_prologue with function end addr Doh! Patch attached. Jifl Index: arm-tdep.c =================================================================== RCS file: /cvs/src/src/gdb/arm-tdep.c,v retrieving revision 1.4 diff -u -5 -p -r1.4 arm-tdep.c --- arm-tdep.c 2000/02/29 07:23:02 1.4 +++ arm-tdep.c 2000/03/18 22:16:21 @@ -326,20 +326,20 @@ arm_frameless_function_invocation (struc When we have found at least one of each class we are done with the prolog. Note that the "sub sp, #NN" before the push does not count. */ static CORE_ADDR -thumb_skip_prologue (CORE_ADDR pc) +thumb_skip_prologue (CORE_ADDR pc, CORE_ADDR func_end) { CORE_ADDR current_pc; int findmask = 0; /* findmask: bit 0 - push { rlist } bit 1 - mov r7, sp OR add r7, sp, #imm (setting of r7) bit 2 - sub sp, #simm OR add sp, #simm (adjusting of sp) */ - for (current_pc = pc; current_pc < pc + 40; current_pc += 2) + for (current_pc = pc; current_pc + 2 < func_end && current_pc < pc + 40; current_pc += 2) { unsigned short insn = read_memory_unsigned_integer (current_pc, 2); if ((insn & 0xfe00) == 0xb400) /* push { rlist } */ { @@ -397,11 +397,11 @@ arm_skip_prologue (CORE_ADDR pc) return sal.end; } /* Check if this is Thumb code. */ if (arm_pc_is_thumb (pc)) - return thumb_skip_prologue (pc); + return thumb_skip_prologue (pc, func_end); /* Can't find the prologue end in the symbol table, try it the hard way by disassembling the instructions. */ skip_pc = pc; inst = read_memory_integer (skip_pc, 4); >From kingdon@redhat.com Sat Apr 01 00:00:00 2000 From: Jim Kingdon To: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH] Comment out longest_raw_hex_string Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: References: <38C0973D.DA06DA51@cygnus.com> X-SW-Source: 2000-q1/msg00508.html Content-length: 452 > The attatched comments out the function longest_raw_hex_string(). It > can be deleted in a month or so (although everyone things it isn't > used). Not that it's a big deal, but in case you want my advice, I'd just delete longest_raw_hex_string now. If there really is some reason to resurrect it, it is in CVS. To think that the #if 0 code would go away as soon as a month is, er, optimistic . >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: Jim Kingdon Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [MAINT] Minor admin tweeks Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38BE0A0E.ED3A565B@cygnus.com> References: <38BC6514.DC70948@cygnus.com> X-SW-Source: 2000-q1/msg00457.html Content-length: 769 Jim Kingdon wrote: > > * MAINTAINERS: Document people with paperwork pending. > > Sorry, I'm a bit confused by this one. Did you mean "+" rather than > "*" for the people you added the symbol to ("*" means that they don't > have an account, according to the key)? > > Philippe De Muyter seems to have the right listing in copyright.html > (1996-06-12). As does JT Conklin (1998-12-21). The ChangeLog entry (poorly worded) in combination with the file changes have thrown a few people. As you note, the footnotes are: * Indicates folks we need to get Kerberos/ssh accounts ready so they can write in the source tree + Indicates folks that have been caught up in a paper trail. I was refering to the ``account request form'' paperwork. Andrew >From jason@cygnus.com Sat Apr 01 00:00:00 2000 From: Jason Merrill To: gdb-patches@sourceware.cygnus.com Subject: Re: dwarf2 class handling patch Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: References: <199911240949.BAA18700@yorick.cygnus.com> X-SW-Source: 2000-q1/msg00015.html Content-length: 2206 Ping? Without this patch, gdb gets things wrong with the current gcc. >>>>> Jason Merrill writes: > The dwarf2 spec says that an incomplete type will have AT_declaration set. > Some changes I'm making to gcc will produce class DIEs with children that > should still be considered incomplete. > 1999-11-24 Jason Merrill > * dwarf2read.c (die_is_declaration): New fn. > (read_structure_scope): Use it. > Index: dwarf2read.c > =================================================================== > RCS file: /cvs/cvsfiles/devo/gdb/dwarf2read.c,v > retrieving revision 2.33 > diff -c -p -r2.33 dwarf2read.c > *** dwarf2read.c 1999/10/11 21:17:22 2.33 > --- dwarf2read.c 1999/11/24 09:38:16 > *************** static void set_cu_language PARAMS ((uns > *** 621,626 **** > --- 621,628 ---- > static struct attribute *dwarf_attr PARAMS ((struct die_info *, > unsigned int)); > + static int die_is_declaration PARAMS ((struct die_info *)); > + > static void dwarf_decode_lines PARAMS ((unsigned int, char *, bfd *)); > static void dwarf2_start_subfile PARAMS ((char *, char *)); > *************** read_structure_scope (die, objfile) > *** 2202,2208 **** > type within the structure itself. */ > die->type = type; > ! if (die->has_children) > { > struct field_info fi; > struct die_info *child_die; > --- 2204,2210 ---- > type within the structure itself. */ > die->type = type; > ! if (die->has_children && ! die_is_declaration (die)) > { > struct field_info fi; > struct die_info *child_die; > *************** dwarf_attr (die, name) > *** 3700,3705 **** > --- 3702,3715 ---- > return NULL; > } > + static int > + die_is_declaration (die) > + struct die_info *die; > + { > + return (dwarf_attr (die, DW_AT_declaration) > + && ! dwarf_attr (die, DW_AT_specification)); > + } > + > /* Decode the line number information for the compilation unit whose > line number info is at OFFSET in the .debug_line section. > The compilation directory of the file is passed in COMP_DIR. */ >From davidw@gordian.com Sat Apr 01 00:00:00 2000 From: David Whedon To: gdb-patches@sourceware.cygnus.com Subject: Re: Deprecating commands; Was: RFC: patch for ... Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: X-SW-Source: 2000-q1/msg00196.html Content-length: 1887 Andrew, Fernando, I'm happy to volunteer. I've given it a start and I think I know where to go with it. I'll probably have something by the weekend. David Andrew Cagney wrote: > > For what its worth, > > Something buried on my to-do / wish list is to extend GDB's command > mechanism so that the user is advised that a command is deprecated the > first time they use it: > > (gdb) othernames xyz > warning: Command `othernames' is deprecated, use `set architecture > abc'. > (gdb) othernames zzz > (gdb) > > Doing that opens up the possibility of moving GDB's CLI (command line > interface) forward. One release would have a poorly chosen command > deprecated. A follow on release could see it (ya!) removed. > > I don't think it is reasonable to simply drop a command (no matter what > the results of a gdb@sourceware straw poll) without some sort of warning > to the general public. > I agree with Andrew. He proposed the "deprecated" mechanism some time ago and it went on our TODO list. Although I am the maintainer of the command line interpreter and I agree with this feature, it was not done because of the major work that we had to do for getting (part of) libgdb out (and people were claiming for it). If someone has the time to contribute with a patch we would appreciate. If not, as soon as possible we will include this "deprecated" state so we can have a graceful phasing out of "bad" commands. Talking about "bad" commands, what can be worse that the "set" overloading? It should only work for gdb control switches. The "set var" should be name "assign". But who dares to change this after 15+ years... -- Fernando Nasser Red Hat - Toronto E-Mail: fnasser@cygnus.com 2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311 Toronto, Ontario M4P 2C9 Fax: 416-482-6299