From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Josef Ezra" To: Subject: Re: bug in tracepoint protocol implementation Date: Tue, 03 Oct 2000 10:29:00 -0000 Message-id: <00e601c02d5f$37d45820$6c219fa8@lss.emc.com> References: <00c801c02c9a$fe671c90$6c219fa8@lss.emc.com> <39D8D1CE.3059@redhat.com> X-SW-Source: 2000-10/msg00015.html Content-type: multipart/mixed; boundary="----------=_1583534358-29877-22" This is a multi-part message in MIME format... ------------=_1583534358-29877-22 Content-length: 1708 (Thanks Michael, I'll try to hit standards this time) The attached fixes an unpleasant bug in trace mechanism. Creating a tracepoint declaration string for remote host, and when more then one memrange item was declared in a tracepoint, the debugger would have leave gaps in the string's buffer, causing unexpected results. Josef Ezra ----- Original Message ----- From: "Michael Snyder" To: "Josef Ezra" Cc: ; ; Sent: Monday, October 02, 2000 2:19 PM Subject: Re: bug in tracepoint protocol implementation > Josef Ezra wrote: > > > > hi > > > > file: tracepoint.c > > function: stringify_collection_list > > > > old: > > count += strlen (end); > > end += count ; > > > > new: > > count += strlen (end); > > end = temp_buf + count ; > > > > reasoning: > > When saving more then one memrange parameter, the old code > > leaves 'gaps' in the temp_buf string. > > Josef, > > Your change is correct (thank you). However, would you > please re-submit it after consulting the file "CONTRIBUTING" > in your gdb source directory? Or see: > http://sources.redhat.com/gdb/#contribute > > Briefly, to streamline the process of accepting GDB > contributions, we request the following format: > > * brief description of the problem being addressed > * ChangeLog entry > * Diff of the changes, such as will be acceptable > as input to "patch" (eg. "cvs diff -c3p tracepoint.c") > > Hate to put you thru the exercise of resubmitting such a > simple patch, but it will be good experience if you intend > to make further GDB contributions (as I hope you will). > > Thanks, > Michael Snyder > ------------=_1583534358-29877-22 Content-Type: text/plain; charset=us-ascii; name="tracepoint.c.diff" Content-Disposition: inline; filename="tracepoint.c.diff" Content-Transfer-Encoding: base64 Content-Length: 891 CgogICAgKnRyYWNlcG9pbnQuYyA6IGJ1ZyBmaXhlZDogc3RyaW5nIHdhcyBj cmVhdGVkIGluIGJvZ3VzCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IG9mZnNldHMuCgoKCioqKiB0cmFjZXBvaW50LmMufjEuMX4JVHVlIE9jdCAg MyAxMjo1NTowNiAyMDAwCi0tLSB0cmFjZXBvaW50LmMufjEuMX5+CVR1ZSBP Y3QgIDMgMTI6NTY6MzQgMjAwMAoqKioqKioqKioqKioqKiogc3RyaW5naWZ5 X2NvbGxlY3Rpb25fbGlzdCAobGlzdCwgc3RyaW5nKQoqKiogMTQ0OCwxNDU0 ICoqKioKICAJICAgICAgIChsb25nKSAobGlzdC0+bGlzdFtpXS5lbmQgLSBs aXN0LT5saXN0W2ldLnN0YXJ0KSk7CiAgCiAgICAgICAgY291bnQgKz0gc3Ry bGVuIChlbmQpOwohICAgICAgIGVuZCArPSBjb3VudDsKICAgICAgfQogIAog ICAgZm9yIChpID0gMDsgaSA8IGxpc3QtPm5leHRfYWV4cHJfZWx0OyBpKysp Ci0tLSAxNDQ4LDE0NTQgLS0tLQogIAkgICAgICAgKGxvbmcpIChsaXN0LT5s aXN0W2ldLmVuZCAtIGxpc3QtPmxpc3RbaV0uc3RhcnQpKTsKICAKICAgICAg ICBjb3VudCArPSBzdHJsZW4gKGVuZCk7CiEgICAgICAgZW5kID0gdGVtcF9i dWYgKyBjb3VudDsKICAgICAgfQogIAogICAgZm9yIChpID0gMDsgaSA8IGxp c3QtPm5leHRfYWV4cHJfZWx0OyBpKyspCg== ------------=_1583534358-29877-22-- >From kevinb@cygnus.com Tue Oct 03 15:44:00 2000 From: Kevin Buettner To: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH RFC] Protoize remote-bug.c, remote-e7000.c Date: Tue, 03 Oct 2000 15:44:00 -0000 Message-id: <1001003224254.ZM30990@ocotillo.lan> References: <1001002010411.ZM5545@ocotillo.lan> X-SW-Source: 2000-10/msg00016.html Content-length: 235 On Oct 1, 6:04pm, Kevin Buettner wrote: > * remote-bug.c (bug_xfer_memory, bug_insert_breakpoint, > bug_remove_breakpoint): Protoize. > * remote-e7000.c (fetch_regs_from_dump, e7000_xfer_inferior_memory): > Protoize. Committed. >From dje@transmeta.com Wed Oct 04 00:35:00 2000 From: Doug Evans To: gdb-patches@sourceware.cygnus.com Cc: Stephane.Carrez@worldnet.fr Subject: nrun-1.patch Date: Wed, 04 Oct 2000 00:35:00 -0000 Message-id: <200010040735.AAA17322@casey.transmeta.com> X-SW-Source: 2000-10/msg00017.html Content-length: 3223 I haven't seen any follow up to my last message on the subject (which I believe was convincing), therefore I'm submitting this patch. Appended is my last message to refresh your memory. :-) 2000-10-04 Doug Evans * common/nrun.c (main): Back out change of Jul 27. Always call sim_info. * m68hc11/interp.c (sim_info): Only print something if STATE_VERBOSE_P. Index: common/nrun.c =================================================================== RCS file: /cvs/src/src/sim/common/nrun.c,v retrieving revision 1.2 diff -c -p -r1.2 nrun.c *** nrun.c 2000/07/27 11:49:07 1.2 --- nrun.c 2000/10/04 07:28:44 *************** main (int argc, char **argv) *** 164,172 **** (STATE_ENVIRONMENT (sd) == OPERATING_ENVIRONMENT)); } /* Print any stats the simulator collected. */ ! if (STATE_VERBOSE_P (sd)) ! sim_info (sd, 0); /* Shutdown the simulator. */ sim_close (sd, 0); --- 164,172 ---- (STATE_ENVIRONMENT (sd) == OPERATING_ENVIRONMENT)); } + /* Print any stats the simulator collected. */ ! sim_info (sd, 0); /* Shutdown the simulator. */ sim_close (sd, 0); Index: m68hc11/interp.c =================================================================== RCS file: /cvs/src/src/sim/m68hc11/interp.c,v retrieving revision 1.3 diff -c -p -r1.3 interp.c *** interp.c 2000/09/10 14:05:29 1.3 --- interp.c 2000/10/04 07:28:44 *************** sim_trace (SIM_DESC sd) *** 302,311 **** void sim_info (SIM_DESC sd, int verbose) { ! sim_io_eprintf (sd, "Simulator info:\n"); ! sim_io_eprintf (sd, " CPU Motorola 68HC11\n"); ! sim_get_info (sd, 0); ! sim_module_info (sd, verbose || STATE_VERBOSE_P (sd)); } SIM_RC --- 302,314 ---- void sim_info (SIM_DESC sd, int verbose) { ! if (STATE_VERBOSE_P (sd)) ! { ! sim_io_eprintf (sd, "Simulator info:\n"); ! sim_io_eprintf (sd, " CPU Motorola 68HC11\n"); ! sim_get_info (sd, 0); ! sim_module_info (sd, 1); ! } } SIM_RC From: Doug Evans Date: Sun, 10 Sep 2000 17:01:59 -0700 (PDT) To: Stephane Carrez Cc: cagney@redhat.com, gdb-patches@sourceware.cygnus.com Subject: Re: nrun.c patch In-Reply-To: <39BBFE2C.28B6D825@worldnet.fr> References: <200009100427.VAA27516@casey.transmeta.com> <39BBADC1.94352650@worldnet.fr> <14779.49324.843786.880750@casey.transmeta.com> <39BBFE2C.28B6D825@worldnet.fr> Stephane Carrez writes: > - several simulator (h8300, h8500, mcore, d10v, sh, w65) are printing statistics > about insn or cpu cycles executed (and I'm doing the same for 68hc11). > None of them are checking flags as you suggest. > > May be the way things were intended to work are not correct and we can fix that. > Now, I just want/need a common way to enable/disable the simulator statistics. Look at it this way. The minute a simulator has more than one thing the user may choose to ask the simulator to print out, sim_info has to test which one the user asked for (which can be none, any combination of, or all). It's simpler and cleaner to just always call sim_info, and let sim_info test for what to print / not print. >From davea@quasar.engr.sgi.com Wed Oct 04 09:13:00 2000 From: David B Anderson To: gdb-patches@sourceware.cygnus.com Subject: dejagnu.texi minor typos Date: Wed, 04 Oct 2000 09:13:00 -0000 Message-id: <200010041613.JAA03382@quasar.engr.sgi.com> X-SW-Source: 2000-10/msg00018.html Content-length: 3284 The following is a suggested patch for src/dejagnu/doc/dejagnu.texi . Spelling corrections only. I did not change the British-spelling 'behaviour' though it takes more space on the page than 'behavior' :-) I don't really know who this should go to, so sending it to the gdb list in hopes that it will be seen by the right person. Suggestions as to what else I should do with this would be welcome. Index: dejagnu.texi =================================================================== RCS file: /cvs/src/src/dejagnu/doc/dejagnu.texi,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 dejagnu.texi --- dejagnu.texi 1999/11/09 01:28:42 1.1.1.1 +++ dejagnu.texi 2000/10/04 16:01:14 @@ -1156,7 +1156,7 @@ procedure, which is discussed elsewhere. @c FIXME: write that section and put an xref here This array can also hold information for a remote host, which is used -when testing a candain cross. In this case, the only thing different is +when testing a canadian cross. In this case, the only thing different is the index is just @code{host}. Here's the settings I use to run tests on my NT machine while running DejaGnu on a Unix machine. (in this case a Linux box) @@ -1290,7 +1290,7 @@ and test a cross compiler on a machine o hosted on. Here we have the config settings for our California office. Note that -all config values are site dependant. Here we have two sets of values +all config values are site dependent. Here we have two sets of values that we use for testing m68k-aout cross compilers. As both of these target boards has a different debugging protocol, we test on both of them in sequence. @@ -1422,7 +1422,7 @@ variable in the top section, then just p second section. Usually the values defined in this config file are related to the configuration of the test run. This is the ideal place to set the variables @code{host_triplet}, @code{build_triplet}, -@code{target_triplet}. All other variables are tool dependant. ie for +@code{target_triplet}. All other variables are tool dependent. ie for testing a compiler, the value for @var{CC} might be set to a freshly built binary, as opposed to one in the user's path. @@ -1881,7 +1881,7 @@ results. @cindex conditional expected failure This procedure adds a condition xfail, based on compiler options used to -create a test case executable. If an include options is found in the +create a test case executable. If an includes option is found in the compiler flags, and it's the right architecture, it'll trigger an XFAIL. Otherwise it'll produce an ordinary FAIL. You can also specify flags to exclude. This makes a result be a FAIL, even if the included @@ -1938,7 +1938,7 @@ set compiler_conditional_xfail_data @{@ What this does is it matches only for these two targets if "-Wall -v" or "-O3" is set, but neither "-O1" or "-Map" is set. - For a set to match, the options specified are searched for independantly of + For a set to match, the options specified are searched for independently of each other, so a "-Wall -v" matches either "-Wall -v" or "-v -Wall". A space seperates the options in the string. Glob-style regular expressions are also permitted. Regards, David B. Anderson davea@sgi.com danderson@acm.org http://reality.sgi.com/davea/ >From kevinb@cygnus.com Wed Oct 04 19:02:00 2000 From: Kevin Buettner To: gdb-patches@sourceware.cygnus.com Subject: [PATCH] rs6000-tdep.c: Improve prologue analysis for PowerPC targets Date: Wed, 04 Oct 2000 19:02:00 -0000 Message-id: <1001005020227.ZM447@ocotillo.lan> X-SW-Source: 2000-10/msg00019.html Content-length: 6968 I've just committed the patch below. It fixes the following failures on powerpc-unknown-linux-gnu: FAIL: gdb.base/recurse.exp: continue to recurse (a = 8) FAIL: gdb.base/recurse.exp: continue to recurse (a = 7) FAIL: gdb.base/recurse.exp: continue to recurse (a = 6) FAIL: gdb.base/recurse.exp: continue to recurse (a = 5) FAIL: gdb.base/recurse.exp: continue to second instance watchpoint, first time FAIL: gdb.base/recurse.exp: continue to recurse (a = 4) FAIL: gdb.base/recurse.exp: continue to recurse (a = 3) FAIL: gdb.base/recurse.exp: continue to recurse (a = 2) FAIL: gdb.base/recurse.exp: continue to recurse (a = 1) FAIL: gdb.base/recurse.exp: continue to second instance watchpoint, second time The above FAILs were related to the testing of watchpoints. Since we have not yet implemented hardware watchpoints for the PowerPC target, gdb is forced to check to see if a particular watchpoint has changed at every instruction. (Yes, this is very slow, since we're reduced to single-stepping the program.) When single-stepping through a function's prologue, there are times at which a full prologue analysis leads the rest of gdb astray. E.g, consider the location at which the return address is saved. On the PowerPC, the return address is available in the link register (lr) at function entry. The prologue is responsible for saving this value on the stack. So, if we're stopped at a point very early in the prologue, before the link register has been saved, it is more accurate for the prologue analysis to not indicate that the return address exists in memory (i.e, on the stack). The patch below merely adds a "limit" parameter to skip_prologue() which will cause the prologue analysis to terminate early if the PC for the frame in question is somewhere within the prologue. Basically, it'll scan up to the limit, but no further. We allow the special case where the limit is 0 to cause the prologue analysis to be performed in its entirety. This is used only in rs6000_skip_prologue() which is called e.g, when setting a breakpoint on a function to find out where the prologue ends. I'm still seeing three recurse.exp FAILs: FAIL: gdb.base/recurse.exp: second instance watchpoint deleted when leaving scope FAIL: gdb.base/recurse.exp: continue to first instance watchpoint, second time FAIL: gdb.base/recurse.exp: first instance watchpoint deleted when leaving scope I believe these are due to the fact that there comes a point in which execution of an epilogue instruction is causing gdb to become confused in much the same way that it was previously confused in the prologue. I haven't decided what to do about these. (I don't think it's worth it to add an epilogue analysis.) Anyway, in addition to fixing the above FAILs, it also now causes backtraces in the prologue to print much more sanely. For example: Before: (gdb) si 0x100003e8 in recurse (a=10) at /ocotillo1/kev/sourceware/src/gdb/testsuite/gdb.base/recurse.c:12 12 { 1: x/i $pc 0x100003e8 : mflr r0 (gdb) bt #0 0x100003e8 in recurse (a=10) at /ocotillo1/kev/sourceware/src/gdb/testsuite/gdb.base/recurse.c:12 #1 0x7ffffcd4 in ?? () After: (gdb) si 0x100003e8 in recurse (a=2147482844) at /ocotillo1/kev/sourceware/src/gdb/testsuite/gdb.base/recurse.c:12 12 { 1: x/i $pc 0x100003e8 : mflr r0 (gdb) bt #0 0x100003e8 in recurse (a=2147482844) at /ocotillo1/kev/sourceware/src/gdb/testsuite/gdb.base/recurse.c:12 #1 0x10000434 in recurse (a=10) at /ocotillo1/kev/sourceware/src/gdb/testsuite/gdb.base/recurse.c:19 #2 0x10000488 in main () at /ocotillo1/kev/sourceware/src/gdb/testsuite/gdb.base/recurse.c:29 #3 0xfebe69c in __libc_start_main (argc=1, argv=0x7ffffcd4, envp=0x7ffffcdc, auxvec=0x7ffffd30, rtld_fini=0x9, stinfo=0x10000568, stack_on_entry=0x0) at ../sysdeps/powerpc/elf/libc-start.c:106 Here's the patch... * rs6000-tdep.c (skip_prologue): Add new parameter lim_pc. Update all callers. Index: rs6000-tdep.c =================================================================== RCS file: /cvs/src/src/gdb/rs6000-tdep.c,v retrieving revision 1.13 diff -u -p -r1.13 rs6000-tdep.c --- rs6000-tdep.c 2000/09/24 09:58:16 1.13 +++ rs6000-tdep.c 2000/10/05 00:45:11 @@ -118,7 +118,8 @@ void (*rs6000_set_host_arch_hook) (int) static CORE_ADDR branch_dest (int opcode, int instr, CORE_ADDR pc, CORE_ADDR safety); -static CORE_ADDR skip_prologue (CORE_ADDR, struct rs6000_framedata *); +static CORE_ADDR skip_prologue (CORE_ADDR, CORE_ADDR, + struct rs6000_framedata *); static void frame_get_saved_regs (struct frame_info * fi, struct rs6000_framedata * fdatap); static CORE_ADDR frame_initial_stack_address (struct frame_info *); @@ -135,7 +136,7 @@ static CORE_ADDR rs6000_skip_prologue (CORE_ADDR pc) { struct rs6000_framedata frame; - pc = skip_prologue (pc, &frame); + pc = skip_prologue (pc, 0, &frame); return pc; } @@ -381,7 +382,7 @@ rs6000_software_single_step (unsigned in #define GET_SRC_REG(x) (((x) >> 21) & 0x1f) static CORE_ADDR -skip_prologue (CORE_ADDR pc, struct rs6000_framedata *fdata) +skip_prologue (CORE_ADDR pc, CORE_ADDR lim_pc, struct rs6000_framedata *fdata) { CORE_ADDR orig_pc = pc; CORE_ADDR last_prologue_pc; @@ -403,7 +404,7 @@ skip_prologue (CORE_ADDR pc, struct rs60 fdata->nosavedpc = 1; pc -= 4; - for (;;) + while (lim_pc == 0 || pc < lim_pc - 4) { pc += 4; @@ -700,7 +701,7 @@ rs6000_pop_frame (void) saved %pc value in the previous frame. */ addr = get_pc_function_start (frame->pc); - (void) skip_prologue (addr, &fdata); + (void) skip_prologue (addr, frame->pc, &fdata); wordsize = TDEP->wordsize; if (fdata.frameless) @@ -1106,7 +1107,7 @@ rs6000_frameless_function_invocation (st return 0; } - (void) skip_prologue (func_start, &fdata); + (void) skip_prologue (func_start, fi->pc, &fdata); return fdata.frameless; } @@ -1132,7 +1133,7 @@ rs6000_frame_saved_pc (struct frame_info if (!func_start) return 0; - (void) skip_prologue (func_start, &fdata); + (void) skip_prologue (func_start, fi->pc, &fdata); if (fdata.lr_offset == 0 && fi->next != NULL) { @@ -1167,7 +1168,7 @@ frame_get_saved_regs (struct frame_info if (fdatap == NULL) { fdatap = &work_fdata; - (void) skip_prologue (get_pc_function_start (fi->pc), fdatap); + (void) skip_prologue (get_pc_function_start (fi->pc), fi->pc, fdatap); } frame_saved_regs_zalloc (fi); @@ -1243,7 +1244,7 @@ frame_initial_stack_address (struct fram /* find out if this function is using an alloca register.. */ - (void) skip_prologue (get_pc_function_start (fi->pc), &fdata); + (void) skip_prologue (get_pc_function_start (fi->pc), fi->pc, &fdata); /* if saved registers of this frame are not known yet, read and cache them. */