From mboxrd@z Thu Jan 1 00:00:00 1970 From: Guy Harris To: Andrew Cagney Cc: Guy Harris , gdb-patches@sourceware.cygnus.com Subject: Re: Patch to let Alpha debuggers debug a remote target over Telnet Date: Wed, 26 Apr 2000 12:00:00 -0000 Message-id: <200004261858.LAA08141@tooting> References: <39066032.1E980CE4@cygnus.com> X-SW-Source: 2000-04/msg00480.html > (I'm now slightly confused. You have been trying this with the current > sources?) "Trying" in what sense? I made sure that it built, but we've not actually been using anything built from the current sources as a debugger for our appliances. >From eliz@delorie.com Wed Apr 26 13:16:00 2000 From: Eli Zaretskii To: kevinb@cygnus.com Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH RFA] config/djgpp/fnchange.lst change for IA-64 Date: Wed, 26 Apr 2000 13:16:00 -0000 Message-id: <200004262016.QAA24197@indy.delorie.com> References: <1000426170421.ZM13236@ocotillo.lan> X-SW-Source: 2000-04/msg00481.html Content-length: 432 > Date: Wed, 26 Apr 2000 10:04:21 -0700 > From: Kevin Buettner > > I request approval for committing the patch below. This patch was > requested by Eli Zaretskii. Note that I decided to follow Mark > Kettenis' advice and mangle the name of ia64-linux-nat.c instead > of ia64-linux-tdep.c. > > * config/djgpp/fnchange.lst (ia64-linux-nat.c): Map to > ia64linux-nat.c. Approved (trunk and branch). Thanks! >From eliz@delorie.com Wed Apr 26 13:18:00 2000 From: Eli Zaretskii To: ac131313@cygnus.com Cc: gdb-patches@sourceware.cygnus.com Subject: Re: gdb/mi add section documenting proposed syntax changes Date: Wed, 26 Apr 2000 13:18:00 -0000 Message-id: <200004262018.QAA24210@indy.delorie.com> References: <3906B478.775F0957@cygnus.com> X-SW-Source: 2000-04/msg00482.html Content-length: 519 > Date: Wed, 26 Apr 2000 19:18:48 +1000 > From: Andrew Cagney > > Look ok? branch? Looks okay as far as the markup goes, except for this: > + * GDB/MI Draft 2.0 Output Syntax:: Periods is a no-no in a node name (some Info browsers, including Emacs, get confused by such node names). Note that there are a few more references to this node name in the patch; they all need to be changed. I cannot say anything about the contents, but other than that, I think it can go into the branch as well. >From msnyder@cygnus.com Wed Apr 26 14:29:00 2000 From: Michael Snyder To: gdb-patches@sourceware.cygnus.com Subject: [PATCH]: hook gdbarch into corefiles. Date: Wed, 26 Apr 2000 14:29:00 -0000 Message-id: <39075FCB.1EBB@cygnus.com> X-SW-Source: 2000-04/msg00483.html Content-length: 963 If no one objects, I will check in the following change. It groks the architecture from a corefile, and passes it to gdbarch (just like is currently done for an executable file). 2000-04-26 Michael Snyder * corelow.c (core_open): call set_gdbarch_from_file so that gdbarch becomes aware of the architecture encoded in the corefile. Index: corelow.c =================================================================== RCS file: /cvs/src/src/gdb/corelow.c,v retrieving revision 1.1.1.6 diff -p -r1.1.1.6 corelow.c *** corelow.c 1999/12/08 02:50:37 1.1.1.6 --- corelow.c 2000/04/26 21:19:11 *************** core_open (filename, from_tty) *** 318,323 **** --- 318,325 ---- error ("\"%s\": Can't find sections: %s", bfd_get_filename (core_bfd), bfd_errmsg (bfd_get_error ())); + set_gdbarch_from_file (core_bfd); + ontop = !push_target (&core_ops); discard_cleanups (old_chain); >From kevinb@cygnus.com Wed Apr 26 14:37:00 2000 From: Kevin Buettner To: Eli Zaretskii Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH RFA] config/djgpp/fnchange.lst change for IA-64 Date: Wed, 26 Apr 2000 14:37:00 -0000 Message-id: <1000426213706.ZM13736@ocotillo.lan> References: <1000426170421.ZM13236@ocotillo.lan> <200004262016.QAA24197@indy.delorie.com> X-SW-Source: 2000-04/msg00484.html Content-length: 748 On Apr 26, 4:16pm, Eli Zaretskii wrote: > > * config/djgpp/fnchange.lst (ia64-linux-nat.c): Map to > > ia64linux-nat.c. > > Approved (trunk and branch). Committed - trunk only. There won't be a conflict on the branch since I haven't added (nor do I plan to add) ia64-linux-tdep.c to the branch. At the time the branch was made, the gdb directory was up-to-date for IA-64, but the opcodes and bfd directories were not. So I'm not going to bother with keeping the branch up-to-date for IA-64 since it won't build anyway. The situation on the trunk has recently changed, however. Jim Wilson has committed the necessary pieces to bfd and opcodes and it is now possible to build a working gdb for IA-64 out of sourceware. (Hooray!) Kevin >From msnyder@cygnus.com Wed Apr 26 14:40:00 2000 From: Michael Snyder To: gdb-patches@sourceware.cygnus.com Subject: [PATCH]: fix compiler warning in java val_print. Date: Wed, 26 Apr 2000 14:40:00 -0000 Message-id: <39076237.3F6A@cygnus.com> X-SW-Source: 2000-04/msg00485.html Content-length: 815 This (a declaration for a function argument) gets rid of a gcc -Wall warning in jv-valprint.c: 2000-04-26 Michael Snyder * jv-valprint.c (java_val_print): add arg declaration, fix compiler warning. Index: jv-valprint.c =================================================================== RCS file: /cvs/src/src/gdb/jv-valprint.c,v retrieving revision 1.1.1.6 diff -p -r1.1.1.6 jv-valprint.c *** jv-valprint.c 2000/02/02 00:21:08 1.1.1.6 --- jv-valprint.c 2000/04/26 21:19:11 *************** java_val_print (type, valaddr, embedded_ *** 454,459 **** --- 454,460 ---- deref_ref, recurse, pretty) struct type *type; char *valaddr; + int embedded_offset; CORE_ADDR address; struct ui_file *stream; int format; >From msnyder@cygnus.com Wed Apr 26 14:44:00 2000 From: msnyder@cygnus.com To: gdb-patches@sourceware.cygnus.com Subject: [PATCH]: multi-arch fix for monitor.c Date: Wed, 26 Apr 2000 14:44:00 -0000 Message-id: <200004262144.OAA05362@seadog.cygnus.com> X-SW-Source: 2000-04/msg00486.html Content-length: 1237 2000-04-26 Michael Snyder * monitor.c (monitor_fetch_register): MAX_REGISTER_RAW_SIZE is not static in the MULTI_ARCH world, so don't use it in a static array declaration. Index: monitor.c =================================================================== RCS file: /cvs/src/src/gdb/monitor.c,v retrieving revision 1.4 diff -c -r1.4 monitor.c *** monitor.c 2000/04/04 02:08:52 1.4 --- monitor.c 2000/04/26 21:41:38 *************** *** 1206,1216 **** int regno; { char *name; ! static char zerobuf[MAX_REGISTER_RAW_SIZE] = ! {0}; ! char regbuf[MAX_REGISTER_RAW_SIZE * 2 + 1]; int i; name = current_monitor->regnames[regno]; monitor_debug ("MON fetchreg %d '%s'\n", regno, name ? name : "(null name)"); --- 1206,1221 ---- int regno; { char *name; ! static char *zerobuf; ! char *regbuf; int i; + if (zerobuf == NULL) + { + zerobuf = alloca (MAX_REGISTER_RAW_SIZE); + memset (zerobuf, 0, MAX_REGISTER_RAW_SIZE); + } + regbuf = alloca (MAX_REGISTER_RAW_SIZE * 2 + 1); name = current_monitor->regnames[regno]; monitor_debug ("MON fetchreg %d '%s'\n", regno, name ? name : "(null name)"); >From msnyder@cygnus.com Wed Apr 26 15:01:00 2000 From: Michael Snyder To: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH]: multi-arch fix for monitor.c Date: Wed, 26 Apr 2000 15:01:00 -0000 Message-id: <3907671D.51B3@cygnus.com> References: <200004262144.OAA05362@seadog.cygnus.com> X-SW-Source: 2000-04/msg00487.html Content-length: 1443 Oops, there's a mistake in here -- please disregard, and I'll resubmit in a few minutes. msnyder@cygnus.com wrote: > > 2000-04-26 Michael Snyder > > * monitor.c (monitor_fetch_register): MAX_REGISTER_RAW_SIZE > is not static in the MULTI_ARCH world, so don't use it in a > static array declaration. > > Index: monitor.c > =================================================================== > RCS file: /cvs/src/src/gdb/monitor.c,v > retrieving revision 1.4 > diff -c -r1.4 monitor.c > *** monitor.c 2000/04/04 02:08:52 1.4 > --- monitor.c 2000/04/26 21:41:38 > *************** > *** 1206,1216 **** > int regno; > { > char *name; > ! static char zerobuf[MAX_REGISTER_RAW_SIZE] = > ! {0}; > ! char regbuf[MAX_REGISTER_RAW_SIZE * 2 + 1]; > int i; > > name = current_monitor->regnames[regno]; > monitor_debug ("MON fetchreg %d '%s'\n", regno, name ? name : "(null name)"); > > --- 1206,1221 ---- > int regno; > { > char *name; > ! static char *zerobuf; > ! char *regbuf; > int i; > > + if (zerobuf == NULL) > + { > + zerobuf = alloca (MAX_REGISTER_RAW_SIZE); > + memset (zerobuf, 0, MAX_REGISTER_RAW_SIZE); > + } > + regbuf = alloca (MAX_REGISTER_RAW_SIZE * 2 + 1); > name = current_monitor->regnames[regno]; > monitor_debug ("MON fetchreg %d '%s'\n", regno, name ? name : "(null name)"); > >From jimb@zwingli.cygnus.com Wed Apr 26 15:17:00 2000 From: Jim Blandy To: Elena Zannoni Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH] in_prologue() fix Date: Wed, 26 Apr 2000 15:17:00 -0000 Message-id: References: <14598.9829.764888.505476@kwikemart.cygnus.com> X-SW-Source: 2000-04/msg00488.html Content-length: 953 > It may be that the real fix is to make ecs->stop_func_start be the > beginning of the function where the adjusted stop_pc is. However that > would require several changes to H.I.E. But in any event in_prologue() > is wrong for this particular case. My first question is, if HIE can find enough symbolic information to set ecs->stop_func_{name,start,end}, how come in_prologue can't find it? In other words: your explanation implies that HIE has some way to find the function extent, but happens to be wrong because of DECR_PC_AFTER_BREAK lossage. But in_prologue knows the correct PC; why can't it use the same mechanism HIE used earlier to get the right answer? Also, aren't there other adverse consequences when ecs->stop_func_{name,start,end} are wrong? I think the HIE fix is the right thing. HIE is painful for me too, but otherwise, you'll just get another CR in a month. If you've tested the change on SPARC and i386, it's okay with me. >From msnyder@cygnus.com Wed Apr 26 15:57:00 2000 From: Michael Snyder To: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH]: multi-arch fix for monitor.c Date: Wed, 26 Apr 2000 15:57:00 -0000 Message-id: <3907743C.BDD@cygnus.com> References: <200004262144.OAA05362@seadog.cygnus.com> X-SW-Source: 2000-04/msg00489.html Content-length: 1250 OK, try #2: 2000-04-26 Michael Snyder * monitor.c (monitor_fetch_register): MAX_REGISTER_RAW_SIZE is not static in the MULTI_ARCH world, so don't use it in a static array declaration. Index: monitor.c =================================================================== RCS file: /cvs/src/src/gdb/monitor.c,v retrieving revision 1.4 diff -c -r1.4 monitor.c *** monitor.c 2000/04/04 02:08:52 1.4 --- monitor.c 2000/04/26 21:41:38 *************** *** 1206,1216 **** int regno; { char *name; ! static char zerobuf[MAX_REGISTER_RAW_SIZE] = ! {0}; ! char regbuf[MAX_REGISTER_RAW_SIZE * 2 + 1]; int i; name = current_monitor->regnames[regno]; monitor_debug ("MON fetchreg %d '%s'\n", regno, name ? name : "(null name)"); --- 1206,1221 ---- int regno; { char *name; ! static char *zerobuf; ! char *regbuf; int i; + if (zerobuf == NULL) + { + zerobuf = malloc (MAX_REGISTER_RAW_SIZE); + memset (zerobuf, 0, MAX_REGISTER_RAW_SIZE); + } + regbuf = alloca (MAX_REGISTER_RAW_SIZE * 2 + 1); name = current_monitor->regnames[regno]; monitor_debug ("MON fetchreg %d '%s'\n", regno, name ? name : "(null name)"); >From ac131313@cygnus.com Wed Apr 26 16:02:00 2000 From: Andrew Cagney To: Guy Harris Cc: gdb-patches@sourceware.cygnus.com Subject: Re: Patch to let Alpha debuggers debug a remote target over Telnet Date: Wed, 26 Apr 2000 16:02:00 -0000 Message-id: <39077516.22FB908E@cygnus.com> References: <200004261858.LAA08141@tooting> X-SW-Source: 2000-04/msg00490.html Content-length: 369 Guy Harris wrote: > > > (I'm now slightly confused. You have been trying this with the current > > sources?) > > "Trying" in what sense? > > I made sure that it built, but we've not actually been using anything > built from the current sources as a debugger for our appliances. Sorry, yes. That is what I ment. The current sources build with the change. Andrew >From ac131313@cygnus.com Wed Apr 26 16:10:00 2000 From: Andrew Cagney To: Michael Snyder Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH]: multi-arch fix for monitor.c Date: Wed, 26 Apr 2000 16:10:00 -0000 Message-id: <39077739.62400899@cygnus.com> References: <200004262144.OAA05362@seadog.cygnus.com> <3907743C.BDD@cygnus.com> X-SW-Source: 2000-04/msg00491.html Content-length: 1554 Michael Snyder wrote: > > OK, try #2: > > 2000-04-26 Michael Snyder > > * monitor.c (monitor_fetch_register): MAX_REGISTER_RAW_SIZE > is not static in the MULTI_ARCH world, so don't use it in a > static array declaration. I'm not so sure :-( MAX_REGISTER_RAW_SIZE can change and hence the allocated size of zerobuf could need to change. What about chaning its only use to write_register (..., 0)? Andrew > > Index: monitor.c > =================================================================== > RCS file: /cvs/src/src/gdb/monitor.c,v > retrieving revision 1.4 > diff -c -r1.4 monitor.c > *** monitor.c 2000/04/04 02:08:52 1.4 > --- monitor.c 2000/04/26 21:41:38 > *************** > *** 1206,1216 **** > int regno; > { > char *name; > ! static char zerobuf[MAX_REGISTER_RAW_SIZE] = > ! {0}; > ! char regbuf[MAX_REGISTER_RAW_SIZE * 2 + 1]; > int i; > > name = current_monitor->regnames[regno]; > monitor_debug ("MON fetchreg %d '%s'\n", regno, name ? name : "(null > name)"); > > --- 1206,1221 ---- > int regno; > { > char *name; > ! static char *zerobuf; > ! char *regbuf; > int i; > > + if (zerobuf == NULL) > + { > + zerobuf = malloc (MAX_REGISTER_RAW_SIZE); > + memset (zerobuf, 0, MAX_REGISTER_RAW_SIZE); > + } > + regbuf = alloca (MAX_REGISTER_RAW_SIZE * 2 + 1); > name = current_monitor->regnames[regno]; > monitor_debug ("MON fetchreg %d '%s'\n", regno, name ? name : "(null > name)"); >From fche@cygnus.com Wed Apr 26 16:15:00 2000 From: fche@cygnus.com (Frank Ch. Eigler) To: gdb-patches@sourceware.cygnus.com Cc: msnyder@cygnus.com Subject: Re: [PATCH]: multi-arch fix for monitor.c Date: Wed, 26 Apr 2000 16:15:00 -0000 Message-id: References: <200004262144.OAA05362@seadog.cygnus.com> <3907743C.BDD@cygnus.com> X-SW-Source: 2000-04/msg00492.html Content-length: 418 msnyder wrote: > ! static char *zerobuf; > + if (zerobuf == NULL) > + zerobuf = malloc (MAX_REGISTER_RAW_SIZE); Something is still a little suspicious. If the gdbarch were to change during run time, there is no way to reallocate space to match the new MAX_REGISTER_RAW_SIZE. That value is treated a de facto constant. Is allocating a new zerobuf too at every call too much work? - FChE >From msnyder@cygnus.com Wed Apr 26 16:26:00 2000 From: msnyder@cygnus.com To: gdb-patches@sourceware.cygnus.com Subject: [PATCH]: int vs. long fixups in proc-api.c Date: Wed, 26 Apr 2000 16:26:00 -0000 Message-id: <200004262326.QAA06052@seadog.cygnus.com> X-SW-Source: 2000-04/msg00493.html Content-length: 3430 I will be checking in the following minor fix-ups: 2000-04-26 Michael Snyder * proc-api.c (write_with_trace): Change 'arg' from long to int. Treat 'off_t' and 'size_t' as unsigned long in printfs. (lseek_with_trace): Treat 'off_t' as unsigned long in printf. Index: proc-api.c =================================================================== RCS file: /cvs/src/src/gdb/proc-api.c,v retrieving revision 1.1.1.1 diff -c -r1.1.1.1 proc-api.c *** proc-api.c 2000/01/25 02:39:49 1.1.1.1 --- proc-api.c 2000/04/26 23:22:27 *************** *** 440,453 **** int write_with_trace (fd, arg, len, file, line) int fd; ! long *arg; size_t len; char *file; int line; { int i; - long opcode = arg[0]; int ret; if (procfs_trace) { --- 440,453 ---- int write_with_trace (fd, arg, len, file, line) int fd; ! int *arg; size_t len; char *file; int line; { int i; int ret; + int opcode = arg[0]; if (procfs_trace) { *************** *** 558,564 **** if (len == sizeof (break_insn) && memcmp (arg, &break_insn, len) == 0) fprintf (procfs_file ? procfs_file : stdout, ! "write () \n", lseek_offset); else if (rw_table[i].name) fprintf (procfs_file ? procfs_file : stdout, "write (%s) %s\n", --- 558,565 ---- if (len == sizeof (break_insn) && memcmp (arg, &break_insn, len) == 0) fprintf (procfs_file ? procfs_file : stdout, ! "write () \n", ! (unsigned long) lseek_offset); else if (rw_table[i].name) fprintf (procfs_file ? procfs_file : stdout, "write (%s) %s\n", *************** *** 568,578 **** { if (lseek_offset != -1) fprintf (procfs_file ? procfs_file : stdout, ! "write (, %d bytes at 0x%08x) \n", ! len, lseek_offset); else fprintf (procfs_file ? procfs_file : stdout, ! "write (, %d bytes) \n", len); } break; } --- 569,580 ---- { if (lseek_offset != -1) fprintf (procfs_file ? procfs_file : stdout, ! "write (, %lud bytes at 0x%08lx) \n", ! (unsigned long) len, (unsigned long) lseek_offset); else fprintf (procfs_file ? procfs_file : stdout, ! "write (, %lud bytes) \n", ! (unsigned long) len); } break; } *************** *** 580,586 **** if (procfs_file) fflush (procfs_file); } ! ret = write (fd, arg, len); if (procfs_trace && ret != len) { fprintf (procfs_file ? procfs_file : stdout, --- 582,588 ---- if (procfs_file) fflush (procfs_file); } ! ret = write (fd, (void *) arg, len); if (procfs_trace && ret != len) { fprintf (procfs_file ? procfs_file : stdout, *************** *** 632,638 **** procfs_file = fopen (procfs_filename, "a"); fprintf (procfs_file ? procfs_file : stdout, ! "[lseek (0x%08x) FAILED!\n", offset); if (procfs_file) fflush (procfs_file); } --- 634,640 ---- procfs_file = fopen (procfs_filename, "a"); fprintf (procfs_file ? procfs_file : stdout, ! "[lseek (0x%08lx) FAILED!\n", (unsigned long) offset); if (procfs_file) fflush (procfs_file); } >From ac131313@cygnus.com Wed Apr 26 16:29:00 2000 From: Andrew Cagney To: Michael Snyder , gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH]: multi-arch fix for monitor.c Date: Wed, 26 Apr 2000 16:29:00 -0000 Message-id: <39077B95.D8EA5F06@cygnus.com> References: <200004262144.OAA05362@seadog.cygnus.com> <3907743C.BDD@cygnus.com> <39077739.62400899@cygnus.com> X-SW-Source: 2000-04/msg00494.html Content-length: 682 Andrew Cagney wrote: > > Michael Snyder wrote: > > > > OK, try #2: > > > > 2000-04-26 Michael Snyder > > > > * monitor.c (monitor_fetch_register): MAX_REGISTER_RAW_SIZE > > is not static in the MULTI_ARCH world, so don't use it in a > > static array declaration. > > I'm not so sure :-( MAX_REGISTER_RAW_SIZE can change and hence the > allocated size of zerobuf could need to change. > > What about chaning its only use to write_register (..., 0)? Sorry, ignore this suggestion. write_register is for high-level accesses to GDB. As Frank suggested, it would be safer to just create the buffer when it is needed. Andrew >From ezannoni@cygnus.com Wed Apr 26 16:35:00 2000 From: Elena Zannoni To: Jim Blandy Cc: Elena Zannoni , gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH] in_prologue() fix Date: Wed, 26 Apr 2000 16:35:00 -0000 Message-id: <14599.32044.511265.33190@kwikemart.cygnus.com> References: <14598.9829.764888.505476@kwikemart.cygnus.com> X-SW-Source: 2000-04/msg00495.html Content-length: 2177 Jim Blandy writes: > > > It may be that the real fix is to make ecs->stop_func_start be the > > beginning of the function where the adjusted stop_pc is. However that > > would require several changes to H.I.E. But in any event in_prologue() > > is wrong for this particular case. > > My first question is, if HIE can find enough symbolic information to > set ecs->stop_func_{name,start,end}, how come in_prologue can't find > it? > I am not sure I understand your question. in_prologue finds the start and end of the function within which pc is (in the same way HIE does for the wrong pc). Because of the way in_prologue works, the info found is not compared with the input function address. Doing this would be another way to fix the problem, but you would have to rewrite in_prologue. What I am trying to say is that in_prologue takes 2 inputs: a pc and a function start address. It has to determine if the pc is within the prologue of the function starting at the address. In this case it gets it wrong because it doesn't think about checking if pc is within the function at all. > In other words: your explanation implies that HIE has some way to find > the function extent, but happens to be wrong because of > DECR_PC_AFTER_BREAK lossage. But in_prologue knows the correct PC; > why can't it use the same mechanism HIE used earlier to get the right > answer? > It does use the same mechanism (find_pc_partial_function) but it doesn't check the results properly. > Also, aren't there other adverse consequences when > ecs->stop_func_{name,start,end} are wrong? I think the HIE fix is the > right thing. HIE is painful for me too, but otherwise, you'll just > get another CR in a month. > So I thought too. But in case of breakpoint being hit, bpstat_stop_status() computes the stop_pc again, and corrects it. All the info is printed correctly. I haven't looked at this in too much detail though. I can add a FIXME to HIE to warn for the possibility of problems down the road. I have no time now to try to fix this. > If you've tested the change on SPARC and i386, it's okay with me. I tested on sparc, I will test on linux. Elena >From msnyder@cygnus.com Wed Apr 26 16:38:00 2000 From: msnyder@cygnus.com To: gdb-patches@sourceware.cygnus.com Subject: [PATCH] Fixups in procfs.c Date: Wed, 26 Apr 2000 16:38:00 -0000 Message-id: <200004262338.QAA06074@seadog.cygnus.com> X-SW-Source: 2000-04/msg00496.html Content-length: 3903 I will check in the following minor fix-ups in procfs: 2000-04-26 Michael Snyder * procfs.c (comments): Eliminate "???" in comments, which GCC wants to interpret as a trigraph. (fill_gregset, supply_gregset, fill_fpregset, supply_fpregset): declare. (procfs_wait): Sysargs is a long, change printf format to match. (test-mapping, mapping_test, test_mapping_cmd) Remove (test only). Index: procfs.c =================================================================== RCS file: /cvs/src/src/gdb/procfs.c,v retrieving revision 1.5 diff -c -r1.5 procfs.c *** procfs.c 2000/04/07 04:33:21 1.5 --- procfs.c 2000/04/26 23:37:20 *************** *** 590,596 **** * Function: create_procinfo * * Allocate a data structure and link it into the procinfo list. ! * (First tries to find a pre-existing one (FIXME: why???) * * Return: pointer to new procinfo struct. */ --- 590,596 ---- * Function: create_procinfo * * Allocate a data structure and link it into the procinfo list. ! * (First tries to find a pre-existing one (FIXME: why?) * * Return: pointer to new procinfo struct. */ *************** *** 3483,3488 **** --- 3483,3495 ---- * is resumed. */ + /* These could go in a header file, but the many and various + definitions of gregset_t would make it tricky... MVS */ + extern void fill_gregset (gdb_gregset_t *, int); + extern void fill_fpregset (gdb_fpregset_t *, int); + extern void supply_gregset (gdb_gregset_t *); + extern void supply_fpregset (gdb_fpregset_t *); + static void procfs_fetch_registers (regno) int regno; *************** *** 3750,3756 **** return a "success" exit code. Bogus: what if it returns something else? */ wstat = 0; ! retval = inferior_pid; /* ??? */ } else { --- 3757,3763 ---- return a "success" exit code. Bogus: what if it returns something else? */ wstat = 0; ! retval = inferior_pid; /* ? ? ? */ } else { *************** *** 3781,3787 **** { printf_filtered ("%ld syscall arguments:\n", nsysargs); for (i = 0; i < nsysargs; i++) ! printf_filtered ("#%ld: 0x%08x\n", i, sysargs[i]); } --- 3788,3794 ---- { printf_filtered ("%ld syscall arguments:\n", nsysargs); for (i = 0; i < nsysargs; i++) ! printf_filtered ("#%ld: 0x%08lx\n", i, sysargs[i]); } *************** *** 3895,3901 **** { printf_filtered ("%ld syscall arguments:\n", nsysargs); for (i = 0; i < nsysargs; i++) ! printf_filtered ("#%ld: 0x%08x\n", i, sysargs[i]); } } --- 3902,3908 ---- { printf_filtered ("%ld syscall arguments:\n", nsysargs); for (i = 0; i < nsysargs; i++) ! printf_filtered ("#%ld: 0x%08lx\n", i, sysargs[i]); } } *************** *** 5192,5218 **** } - int - mapping_test (fd, core_addr) - int fd; - CORE_ADDR core_addr; - { - printf ("File descriptor %d, base address 0x%08x\n", fd, core_addr); - if (fd > 0) - close (fd); - return 0; - } - - void - test_mapping_cmd (args, from_tty) - char *args; - int from_tty; - { - int ret; - ret = proc_iterate_over_mappings (mapping_test); - printf ("iterate_over_mappings returned %d.\n", ret); - } - void _initialize_procfs () { --- 5199,5204 ---- *************** *** 5229,5237 **** "Cancel a trace of entries into the syscall."); add_com ("proc-untrace-exit", no_class, proc_untrace_sysexit_cmd, "Cancel a trace of exits from the syscall."); - - add_com ("test-mapping", no_class, test_mapping_cmd, - "test iterate-over-mappings"); } /* =================== END, GDB "MODULE" =================== */ --- 5215,5220 ---- >From ac131313@cygnus.com Wed Apr 26 16:41:00 2000 From: Andrew Cagney To: Eli Zaretskii Cc: gdb-patches@sourceware.cygnus.com Subject: Re: gdb/mi add section documenting proposed syntax changes Date: Wed, 26 Apr 2000 16:41:00 -0000 Message-id: <39077E6C.C2699B3E@cygnus.com> References: <3906B478.775F0957@cygnus.com> <200004262018.QAA24210@indy.delorie.com> X-SW-Source: 2000-04/msg00497.html Content-length: 559 Eli Zaretskii wrote: > > > Date: Wed, 26 Apr 2000 19:18:48 +1000 > > From: Andrew Cagney > > > > Look ok? branch? > > Looks okay as far as the markup goes, except for this: > > > + * GDB/MI Draft 2.0 Output Syntax:: > Periods is a no-no in a node name (some Info browsers, including > Emacs, get confused by such node names). Ok. I've changed the title to ``Draft Changes to Output Syntax''. > I cannot say anything about the contents, but other than that, I think > it can go into the branch as well. Yes, fair enough. Andrew >From ac131313@cygnus.com Wed Apr 26 16:43:00 2000 From: Andrew Cagney To: msnyder@cygnus.com Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH] Fixups in procfs.c Date: Wed, 26 Apr 2000 16:43:00 -0000 Message-id: <39077EE1.EB13C35D@cygnus.com> References: <200004262338.QAA06074@seadog.cygnus.com> X-SW-Source: 2000-04/msg00499.html Content-length: 970 msnyder@cygnus.com wrote: > > I will check in the following minor fix-ups in procfs: > > 2000-04-26 Michael Snyder > > * procfs.c (comments): Eliminate "???" in comments, which GCC > wants to interpret as a trigraph. (fill_gregset, supply_gregset, > fill_fpregset, supply_fpregset): declare. > (procfs_wait): Sysargs is a long, change printf format to match. > (test-mapping, mapping_test, test_mapping_cmd) Remove (test only). > > + /* These could go in a header file, but the many and various > + definitions of gregset_t would make it tricky... MVS */ > + extern void fill_gregset (gdb_gregset_t *, int); > + extern void fill_fpregset (gdb_fpregset_t *, int); > + extern void supply_gregset (gdb_gregset_t *); > + extern void supply_fpregset (gdb_fpregset_t *); > + Michael, This change has to be wrong. The extern declaration should be comming from a header file somewhere. Andrew >From msnyder@cygnus.com Wed Apr 26 16:43:00 2000 From: Michael Snyder To: Andrew Cagney Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH]: multi-arch fix for monitor.c Date: Wed, 26 Apr 2000 16:43:00 -0000 Message-id: <39077F1C.4D2E@cygnus.com> References: <200004262144.OAA05362@seadog.cygnus.com> <3907743C.BDD@cygnus.com> <39077739.62400899@cygnus.com> <39077B95.D8EA5F06@cygnus.com> X-SW-Source: 2000-04/msg00498.html Content-length: 1026 Andrew Cagney wrote: > > Andrew Cagney wrote: > > > > Michael Snyder wrote: > > > > > > OK, try #2: > > > > > > 2000-04-26 Michael Snyder > > > > > > * monitor.c (monitor_fetch_register): MAX_REGISTER_RAW_SIZE > > > is not static in the MULTI_ARCH world, so don't use it in a > > > static array declaration. > > > > I'm not so sure :-( MAX_REGISTER_RAW_SIZE can change and hence the > > allocated size of zerobuf could need to change. > > > > What about chaning its only use to write_register (..., 0)? > > Sorry, ignore this suggestion. write_register is for high-level > accesses to GDB. As Frank suggested, it would be safer to just create > the buffer when it is needed. That's why I keep you guys around. ;-) Here is the new patch. 2000-04-26 Michael Snyder * monitor.c (monitor_fetch_register): MAX_REGISTER_RAW_SIZE is not static in the MULTI_ARCH world, so don't use it in a static array declaration. >From ac131313@cygnus.com Wed Apr 26 16:46:00 2000 From: Andrew Cagney To: Tim Mooney , GDB Patches Subject: Re: [Fwd: [Fwd: gdb 20000413 compile problem and strange SEGV problem]] Date: Wed, 26 Apr 2000 16:46:00 -0000 Message-id: <39077F74.1F47EE94@cygnus.com> References: <39014F1B.47DB6E05@cygnus.com> X-SW-Source: 2000-04/msg00500.html Content-length: 990 Andrew Cagney wrote: > > By ``object'' did you mean a warning or an error? > > > I downloaded gdb+dejagnu-20000413.tar.bz2 and encountered one problem building > > it with the Compaq compiler: the compiler objected to comparisons between > > {current,debug}_target.to_rcmd and tcomplain (which was being case to (void > > *)). I'm not sure why the cast to (void *) is there at all, but my first > > thought was to try casting tcomplain to be a pointer to a function, > > and that worked. This is the patch I used: > > Your change makes sense. It was cast to (void*) since the functions > to_rcmd() and tcomplain() were not type incompatible. The compaq > compiler is more picky about such things. FYI, I've just checked and GDB-5.0 build on an ``OSF1 V4.0 464 alpha'' using both GCC and the native CC. I'll assume that these were compiler warnings rather than fatal compiler errors. Consequently the cleanups should get merged into the trunk but not the GDB-5.0 branch. Andrew >From msnyder@cygnus.com Wed Apr 26 16:54:00 2000 From: Michael Snyder To: Andrew Cagney Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH] Fixups in procfs.c Date: Wed, 26 Apr 2000 16:54:00 -0000 Message-id: <390781C8.5838@cygnus.com> References: <200004262338.QAA06074@seadog.cygnus.com> <39077EE1.EB13C35D@cygnus.com> X-SW-Source: 2000-04/msg00501.html Content-length: 1895 Andrew Cagney wrote: > > msnyder@cygnus.com wrote: > > > > I will check in the following minor fix-ups in procfs: > > > > 2000-04-26 Michael Snyder > > > > * procfs.c (comments): Eliminate "???" in comments, which GCC > > wants to interpret as a trigraph. (fill_gregset, supply_gregset, > > fill_fpregset, supply_fpregset): declare. > > (procfs_wait): Sysargs is a long, change printf format to match. > > (test-mapping, mapping_test, test_mapping_cmd) Remove (test only). > > > > > + /* These could go in a header file, but the many and various > > + definitions of gregset_t would make it tricky... MVS */ > > + extern void fill_gregset (gdb_gregset_t *, int); > > + extern void fill_fpregset (gdb_fpregset_t *, int); > > + extern void supply_gregset (gdb_gregset_t *); > > + extern void supply_fpregset (gdb_fpregset_t *); > > + > > Michael, > > This change has to be wrong. The extern declaration should be comming > from a header file somewhere. I appreciate the sentiment (as reflected by my comment). There are currently 15 (fifteen) implementations of these four functions. Thirteen of them have an argument of type "gregset_t", one has a "prgregset_t", and one has an "elf_gregset_t". None of these functions is declared in any header file. The type itself comes from various different system header files, depending on the native OS. To cope with this divergence, procfs has its own typedef "gdb_gregset_t" which is declared in various different ways inside an ugly ifdef. It calls the function with that, and if all goes well, the actual argument will match the appropriate version of the formal argument. I did not think this ugliness ought to be exported up into a local header file, since there are very few users of this API. And anyway, I was only trying to suppress a compiler warning. >From ac131313@cygnus.com Wed Apr 26 16:56:00 2000 From: Andrew Cagney To: Elena Zannoni Cc: Guy Harris , gdb-patches@sourceware.cygnus.com Subject: Re: Patch to make top-of-tree GDB compile on Digital UNIX Date: Wed, 26 Apr 2000 16:56:00 -0000 Message-id: <390781AF.AB20C802@cygnus.com> References: <200004220016.RAA02113@tooting> <14596.24388.209049.765129@kwikemart.cygnus.com> X-SW-Source: 2000-04/msg00502.html Content-length: 1930 Elena Zannoni wrote: > Index: osfsolib.c > =================================================================== > RCS file: /cvs/src/src/gdb/osfsolib.c,v > retrieving revision 1.2 > diff -c -r1.2 osfsolib.c > *** osfsolib.c 2000/04/04 02:08:52 1.2 > --- osfsolib.c 2000/04/24 14:42:07 > *************** > *** 598,604 **** > text_addr = bfd_section_vma (so->abfd, lowest_sect) + LM_OFFSET (so); > } > > ! section_addrs.text_addr = text_addr; > so->objfile = symbol_file_add (so->so_name, so->from_tty, > §ion_addrs, 0, OBJF_SHARED); > return (1); > --- 598,605 ---- > text_addr = bfd_section_vma (so->abfd, lowest_sect) + LM_OFFSET (so); > } > > ! section_addrs.other[0].addr = text_addr; > ! section_addrs.other[0].name = ".text"; > so->objfile = symbol_file_add (so->so_name, so->from_tty, > §ion_addrs, 0, OBJF_SHARED); > return (1); > I see Elena is working through all the fixes like the above (Thanks)! > I don't think we have a maintainer for this platform, do we? > Elena Which means it is me .... > > I also changed "symbol_add_stub()" and "solib_map_sections()" to take a > > "PTR" rather than a "char *" as an argument, similar to the signatures > > they have in other "*solib.c" files, to eliminate some compiler > > warnings; Elena Zannoni suggested to me that "PTR" is deprecated in > > favor of "void *", so perhaps "void *" should be used instead. That is correct. The output of `grep PTR *.[hc] | wc -l` should be going down not up :-) Elena also noted that the patch combined two very different changes. It's really important to keep cleanups separate from bug fixes. You may find it easier if you have two or more copies of the the GDB source tree. That way one tree can be used to create clean patches while another is used for experimentation. enjoy, Andrew >From ac131313@cygnus.com Wed Apr 26 17:04:00 2000 From: Andrew Cagney To: Michael Snyder Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH] Fixups in procfs.c Date: Wed, 26 Apr 2000 17:04:00 -0000 Message-id: <390783BF.F84078D4@cygnus.com> References: <200004262338.QAA06074@seadog.cygnus.com> <39077EE1.EB13C35D@cygnus.com> <390781C8.5838@cygnus.com> X-SW-Source: 2000-04/msg00503.html Content-length: 1160 Michael Snyder wrote: > > > Michael, > > > > This change has to be wrong. The extern declaration should be comming > > from a header file somewhere. > > I appreciate the sentiment (as reflected by my comment). > There are currently 15 (fifteen) implementations of these > four functions. Thirteen of them have an argument of type > "gregset_t", one has a "prgregset_t", and one has an > "elf_gregset_t". None of these functions is declared in any > header file. The type itself comes from various different > system header files, depending on the native OS. > > To cope with this divergence, procfs has its own typedef > "gdb_gregset_t" which is declared in various different ways > inside an ugly ifdef. It calls the function with that, and > if all goes well, the actual argument will match the appropriate > version of the formal argument. > > I did not think this ugliness ought to be exported up > into a local header file, since there are very few users > of this API. And anyway, I was only trying to suppress > a compiler warning. Ok (ulgh). I'd suggest expanding on the comment a little with what you've explained above. sorry, Andrew >From guy@netapp.com Wed Apr 26 17:06:00 2000 From: Guy Harris To: Andrew Cagney Cc: Elena Zannoni , Guy Harris , gdb-patches@sourceware.cygnus.com Subject: Re: Patch to make top-of-tree GDB compile on Digital UNIX Date: Wed, 26 Apr 2000 17:06:00 -0000 Message-id: <200004270006.RAA24862@tooting> References: <390781AF.AB20C802@cygnus.com> X-SW-Source: 2000-04/msg00504.html Content-length: 848 > Elena also noted that the patch combined two very different changes. If you're referring to her comment Your changes to symbol_add_stub are actually more than what necessary for compilation. You have added the use of the function build_section_addr_info_from_section_table() which Kevin Buettner introduced for other purposes a few weeks back. it was, at least as I was constructing it, only one change, as I'd inferred, perhaps incorrectly, from other changes that the changes to use "build_section_addr_info_from_section_table()" *were* the way to fix the compilation problem; they weren't an attempt on my part to experimentally clean the code up. I don't particularly care how it's fixed, as long as it compiles and works; if the changes Elena suggested are sufficient to get it to build and work, you might as well go with those. >From ac131313@cygnus.com Wed Apr 26 17:08:00 2000 From: Andrew Cagney To: David Whedon Cc: gdb-patches@sourceware.cygnus.com Subject: Re: problem with 5.0 branch building on irix (arm target) Date: Wed, 26 Apr 2000 17:08:00 -0000 Message-id: <3907848E.B4FCF4FE@cygnus.com> References: X-SW-Source: 2000-04/msg00505.html Content-length: 196 David Whedon wrote: > > Maybe my situation is too obscure, and you all shouldn't be bothered. If > so let me know. I've not seen any responses so I've added a note to the TODO file :-( Andrew >From msnyder@cygnus.com Wed Apr 26 17:14:00 2000 From: Michael Snyder To: Andrew Cagney Cc: David Taylor , gdb-patches@sourceware.cygnus.com Subject: Re: [RFC]: internal_error should call target_terminal_ours Date: Wed, 26 Apr 2000 17:14:00 -0000 Message-id: <3907866D.1844@cygnus.com> References: <200003292312.SAA26979@texas.cygnus.com> <38E29C4F.72C114E3@cygnus.com> X-SW-Source: 2000-04/msg00506.html Content-length: 2462 Andrew Cagney wrote: > > David Taylor wrote: > > > > Date: Wed, 29 Mar 2000 12:10:02 -0800 > > From: Michael Snyder > > > > I just encountered a situation where internal_error was called > > while the target program was running, resulting in the following: > > > > gdb-internal-error: gdbarch: gdbarch_breakpoint_from_pc invalid > > An internal GDB error was detected. This may make make further > > debugging unreliable. Continue this debugging session? (y or n) > > Suspended (tty input) > > %] msnyder<547>% > > > > As you can see, instead of waiting for my input, GDB suspended > > because it didn't own the tty. > > > > It's probably a bad thing (tm) to call internal_error while the > > inferior is running, but in case it does happen, I wonder what > > people think about the following? > > > > I think that you're right that adding target_terminal_ours would be a > > good thing. But, my inclination is to put it closer to the actual i/o > > -- namely in internal_verror rather than internal_error. > > > > Additionally, looking at internal_verror, I think that it should call > > quit_force rather than calling exit -- as it is now it just abandons > > the target. > > My only thought is that I'm not sure if target_terminal_ours() is > idenpotent. See remote.c where, due to async, it was being called > multiple times. I ended up adding code to make the functions > idenpotent. Should that code be moved to target.c? > > David's made a good point. Everything goes through internal_verror(). > Hey, i planned it that way :-) Oops -- I let this one sleep in my sandbox for a while. Since no one else has chimed in, I will make the change that Andrew and David suggested, and check it in. Here is the change for posterity: 2000-04-26 Michael Snyder * utils.c (internal_verror): Call target_terminal_ours. Index: utils.c =================================================================== RCS file: /cvs/src/src/gdb/utils.c,v retrieving revision 1.7 diff -c -r1.7 utils.c *** utils.c 2000/04/21 04:10:18 1.7 --- utils.c 2000/04/27 00:13:21 *************** *** 680,685 **** --- 680,686 ---- } /* Try to get the message out */ + target_terminal_ours (); fputs_unfiltered ("gdb-internal-error: ", gdb_stderr); vfprintf_unfiltered (gdb_stderr, fmt, ap); fputs_unfiltered ("\n", gdb_stderr); >From jimb@zwingli.cygnus.com Wed Apr 26 17:25:00 2000 From: Jim Blandy To: gdb-patches@sourceware.cygnus.com Subject: RFA: print addresses that are longer than pointers Date: Wed, 26 Apr 2000 17:25:00 -0000 Message-id: <200004270025.TAA03409@zwingli.cygnus.com> X-SW-Source: 2000-04/msg00507.html Content-length: 2307 This is yet a third amendment to address printing in printcmd.c. I recently made changes which allow GDB to handle architectures on which addresses are larger than pointers. However, the code which Peter Schauer added to printcmd.c to handle unwanted sign extension assumes that addresses and pointers are the same size. As it turns out, this masking is unnecessary when the value being printed is a genuine pointer; the sign extension won't occur, and the masking is unneeded. This also rewrites the mask generation in a way which I think is overflow-free, without needing to pull the wool over the compiler's eyes. 2000-04-26 Jim Blandy * printcmd.c (print_scalar_formatted): Addresses may be longer than pointers. If the value we're printing is a genuine pointer, assume that unpack_pointer will do the right thing. Index: gdb/printcmd.c =================================================================== RCS file: /cvs/cvsfiles/devo/gdb/printcmd.c,v retrieving revision 1.163 diff -c -r1.163 printcmd.c *** gdb/printcmd.c 2000/04/16 14:53:33 1.163 --- gdb/printcmd.c 2000/04/27 00:20:36 *************** *** 444,457 **** case 'a': { ! /* Truncate address to the size of a target pointer, avoiding ! shifts larger or equal than the width of a CORE_ADDR. The ! local variable PTR_BIT stops the compiler reporting a shift ! overflow when it won't occure. */ CORE_ADDR addr = unpack_pointer (type, valaddr); ! int ptr_bit = TARGET_PTR_BIT; ! if (ptr_bit < (sizeof (CORE_ADDR) * HOST_CHAR_BIT)) ! addr &= ((CORE_ADDR) 1 << ptr_bit) - 1; print_address (addr, stream); } break; --- 444,459 ---- case 'a': { ! /* If the value is actually a pointer, then unpack_pointer ! will do the right thing. If the value is not a pointer, ! but happens to be a signed type, then unpack_pointer may ! sign-extend it; in this case, we trim it to the size of a ! pointer. */ CORE_ADDR addr = unpack_pointer (type, valaddr); ! if (TYPE_CODE (type) != TYPE_CODE_PTR) ! /* When building the mask, avoid shifts larger or equal than ! the width of a CORE_ADDR. */ ! addr &= (((CORE_ADDR) 1 << (TARGET_PTR_BIT - 1)) << 1) + 1; print_address (addr, stream); } break; >From msnyder@cygnus.com Wed Apr 26 17:27:00 2000 From: Michael Snyder To: gdb-patches@sourceware.cygnus.com Subject: [RFC]: export write_register_gen Date: Wed, 26 Apr 2000 17:27:00 -0000 Message-id: <39078958.24CC@cygnus.com> X-SW-Source: 2000-04/msg00508.html Content-length: 1110 The module findvar.c has at least three different interfaces for accessing GDB's internal cache of register values: CORE_ADDR read_register (int regno); void write_register (int regno, LONGEST val); void read_register_bytes (int inregbyte, char *myaddr, int inlen); void write_register_bytes (int inregbyte, char *myaddr, int inlen); void read_register_gen (int regno, char *myaddr); static void write_register_gen (int regno, char *myaddr); If you're dealing with a host LONGEST or CORE_ADDR, then the preferred interface is read_register/write_register. However if you're dealing with a buffer of bytes in target byte order, you would use one of the other two. And by far the easiest to use is [read/write]_register_gen. You would only need to use [read/write]_register_bytes if the stream of bytes you have might cross the boundary between two registers (or start in the middle of one). Yet write_register_gen is declared static. I thought I was going to need it, so I wanted to export it. It turns out that I don't need it, but I still think it should be public. Thoughts? Michael >From jimb@zwingli.cygnus.com Wed Apr 26 17:29:00 2000 From: Jim Blandy To: gdb-patches@sourceware.cygnus.com Subject: RECALL PATCH: print addresses that are longer than pointers Date: Wed, 26 Apr 2000 17:29:00 -0000 Message-id: <200004270029.TAA03414@zwingli.cygnus.com> X-SW-Source: 2000-04/msg00509.html Content-length: 100 My patch reintroduces the regression Peter was trying to fix in the first place. I'll resubmit it. >From ac131313@cygnus.com Wed Apr 26 17:33:00 2000 From: Andrew Cagney To: GDB Patches , powerpc-psim@ci.com.au Subject: [psim] Fix to events.c assertion failure Date: Wed, 26 Apr 2000 17:33:00 -0000 Message-id: <39078A7E.857D58AD@cygnus.com> X-SW-Source: 2000-04/msg00510.html Content-length: 4349 Hello, The attatched patch hopefully fixes an assertion failure in events.c that several people were reporting. Can people please let me know how it goes (quickly, the 5.0 boat is now departing...) I should note that the patch as it stands contains additions to the event tracing, I'll be separating that out when it comes to the actual checkin. Andrew Wed Apr 26 16:08:42 2000 Andrew Cagney * events.c (event_queue_process): Call update_time_from_event every time an event is removed from the queue. (update_time_from_event): Delete assertion that a negative time_from_event implies an empty event queue. Add more tracing. Index: events.c =================================================================== RCS file: /cvs/src/src/sim/ppc/events.c,v retrieving revision 1.1.1.1 diff -p -r1.1.1.1 events.c *** events.c 1999/04/16 01:35:09 1.1.1.1 --- events.c 2000/04/26 06:33:28 *************** update_time_from_event(event_queue *even *** 161,168 **** events->time_of_event = current_time - 1; events->time_from_event = -1; } ASSERT(current_time == event_queue_time(events)); - ASSERT((events->time_from_event >= 0) == (events->queue != NULL)); } STATIC_INLINE_EVENTS\ --- 161,185 ---- events->time_of_event = current_time - 1; events->time_from_event = -1; } + if (WITH_TRACE && ppc_trace[trace_events]) + { + event_entry *event; + int i; + for (event = events->queue, i = 0; + event != NULL; + event = event->next, i++) + { + TRACE(trace_events, ("event time-from-event - time %ld, delta %ld - event %d, tag 0x%lx, time %ld, handler 0x%lx, data 0x%lx\n", + (long)current_time, + (long)events->time_from_event, + i, + (long)event, + (long)event->time_of_event, + (long)event->handler, + (long)event->data)); + } + } ASSERT(current_time == event_queue_time(events)); } STATIC_INLINE_EVENTS\ *************** event_queue_process(event_queue *events) *** 369,386 **** event_handler *handler = to_do->handler; void *data = to_do->data; events->queue = to_do->next; ! TRACE(trace_events, ("event issued at %ld - tag 0x%lx - handler 0x%lx, data 0x%lx\n", (long)event_time, (long)to_do, (long)handler, (long)data)); zfree(to_do); handler(data); } events->processing = 0; ! /* re-caculate time for new events */ ! update_time_from_event(events); } --- 386,407 ---- event_handler *handler = to_do->handler; void *data = to_do->data; events->queue = to_do->next; ! TRACE(trace_events, ("event issued at %ld - tag 0x%lx - time %ld, handler 0x%lx, data 0x%lx\n", (long)event_time, (long)to_do, + (long)to_do->time_of_event, (long)handler, (long)data)); zfree(to_do); + /* Always re-compute the time to the next event so that HANDLER() + can safely insert new events into the queue. */ + update_time_from_event(events); handler(data); } events->processing = 0; ! ASSERT(events->time_from_event > 0); ! ASSERT(events->queue != NULL); /* always poll event */ } Index: interrupts.c =================================================================== RCS file: /cvs/src/src/sim/ppc/interrupts.c,v retrieving revision 1.1.1.2 diff -p -r1.1.1.2 interrupts.c *** interrupts.c 1999/04/26 18:33:26 1.1.1.2 --- interrupts.c 2000/04/26 06:33:28 *************** deliver_hardware_interrupt(void *data) *** 469,475 **** unsigned_word cia = cpu_get_program_counter(processor); unsigned_word nia = perform_oea_interrupt(processor, cia, 0x00900, 0, 0, 0, 0); ! TRACE(trace_interrupts, ("decrementer interrupt - cia=0x%lx time=0x%lx\n", (unsigned long)cia, (unsigned long)event_queue_time(psim_event_queue(cpu_system(processor))) )); --- 469,475 ---- unsigned_word cia = cpu_get_program_counter(processor); unsigned_word nia = perform_oea_interrupt(processor, cia, 0x00900, 0, 0, 0, 0); ! TRACE(trace_interrupts, ("decrementer interrupt - cia 0x%lx, time %ld\n", (unsigned long)cia, (unsigned long)event_queue_time(psim_event_queue(cpu_system(processor))) )); >From msnyder@cygnus.com Wed Apr 26 17:39:00 2000 From: msnyder@cygnus.com To: gdb-patches@sourceware.cygnus.com Subject: [PATCH]: testsuite tweak for Sparclet Date: Wed, 26 Apr 2000 17:39:00 -0000 Message-id: <200004270038.RAA06208@seadog.cygnus.com> X-SW-Source: 2000-04/msg00511.html Content-length: 2093 The sparclet remote stub does not support stdio, so these tests, which depend on parsing the output of the program, will never run. There are probably others with the same problem -- these are just the ones I happened to catch. 2000-04-26 Michael Snyder * gdb.base/call-ar-st.exp: Bail out if target is sparclet. This test depends on parsing the printf output from the target. Since the sparclet stub doesn't do stdio, this will never work. * gdb.base/call-rt-st.exp: ditto. Index: gdb.base/call-ar-st.exp =================================================================== RCS file: /cvs/src/src/gdb/testsuite/gdb.base/call-ar-st.exp,v retrieving revision 1.3 diff -p -r1.3 call-ar-st.exp *** call-ar-st.exp 2000/04/08 05:10:43 1.3 --- call-ar-st.exp 2000/04/27 00:37:13 *************** set testfile "call-ar-st" *** 32,37 **** --- 32,40 ---- set srcfile ${testfile}.c set binfile ${objdir}/${subdir}/${testfile} + if { [istarget "sparclet-*-*"] } { + return 0; + } if { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug}] != "" } { gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail." *************** gdb_expect { *** 567,571 **** } return - ~ --- 570,574 ---- } return + Index: gdb.base/call-rt-st.exp =================================================================== RCS file: /cvs/src/src/gdb/testsuite/gdb.base/call-rt-st.exp,v retrieving revision 1.1.1.3 diff -p -r1.1.1.3 call-rt-st.exp *** call-rt-st.exp 1999/06/28 16:02:48 1.1.1.3 --- call-rt-st.exp 2000/04/27 00:37:13 *************** set srcfile ${testfile}.c *** 36,41 **** --- 36,45 ---- set binfile ${objdir}/${subdir}/${testfile} + if { [istarget "sparclet-*-*"] } { + return 0; + } + if { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug additional_flags=-w}] != "" } { gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail." } >From msnyder@cygnus.com Wed Apr 26 18:10:00 2000 From: msnyder@cygnus.com To: gdb-patches@sourceware.cygnus.com Subject: [PATCH]: multi-arch tweak for sparclet-rom.c Date: Wed, 26 Apr 2000 18:10:00 -0000 Message-id: <200004270110.SAA06267@seadog.cygnus.com> X-SW-Source: 2000-04/msg00512.html Content-length: 2251 To get away from using the REGISTER_NAMES macro, it's necessary to initialize this local array of register names explicitly. I know it is ugly to just duplicate the list of names found in the tm.h file, but that is what most other existing rom modules do. The monitor mechanism depends on having its own local copy of this array of string names. 2000-04-26 Michael Snyder * sparclet-rom.c (sparclet_regnames): Initialize this array explicitly rather than use the REGISTER_NAMES macro (which must eventually go away for Multi-Arch). Index: sparclet-rom.c =================================================================== RCS file: /cvs/src/src/gdb/sparclet-rom.c,v retrieving revision 1.1.1.2 diff -c -r1.1.1.2 sparclet-rom.c *** sparclet-rom.c 1999/07/07 20:10:12 1.1.1.2 --- sparclet-rom.c 2000/04/27 01:07:58 *************** *** 61,67 **** /* is wim part of psr?? */ /* monitor wants lower case */ ! static char *sparclet_regnames[NUM_REGS] = REGISTER_NAMES; /* Function: sparclet_supply_register --- 61,92 ---- /* is wim part of psr?? */ /* monitor wants lower case */ ! static char *sparclet_regnames[] = { ! "g0", "g1", "g2", "g3", "g4", "g5", "g6", "g7", ! "o0", "o1", "o2", "o3", "o4", "o5", "o6", "o7", ! "l0", "l1", "l2", "l3", "l4", "l5", "l6", "l7", ! "i0", "i1", "i2", "i3", "i4", "i5", "i6", "i7", ! ! "", "", "", "", "", "", "", "", /* no FPU regs */ ! "", "", "", "", "", "", "", "", ! "", "", "", "", "", "", "", "", ! "", "", "", "", "", "", "", "", ! /* no CPSR, FPSR */ ! "y", "psr", "wim", "tbr", "pc", "npc", "", "", ! ! "ccsr", "ccpr", "cccrcr", "ccor", "ccobr", "ccibr", "ccir", "", ! ! /* ASR15 ASR19 (don't display them) */ ! "asr1", "", "asr17", "asr18", "", "asr20", "asr21", "asr22", ! /* ! "awr0", "awr1", "awr2", "awr3", "awr4", "awr5", "awr6", "awr7", ! "awr8", "awr9", "awr10", "awr11", "awr12", "awr13", "awr14", "awr15", ! "awr16", "awr17", "awr18", "awr19", "awr20", "awr21", "awr22", "awr23", ! "awr24", "awr25", "awr26", "awr27", "awr28", "awr29", "awr30", "awr31", ! "apsr", ! */ ! }; ! /* Function: sparclet_supply_register >From mooney@dogbert.cc.ndsu.nodak.edu Wed Apr 26 18:15:00 2000 From: Tim Mooney To: Andrew Cagney Cc: GDB Patches Subject: Re: [Fwd: [Fwd: gdb 20000413 compile problem and strange SEGVproblem]] Date: Wed, 26 Apr 2000 18:15:00 -0000 Message-id: References: <39077F74.1F47EE94@cygnus.com> X-SW-Source: 2000-04/msg00513.html Content-length: 2078 In regard to: Re: [Fwd: [Fwd: gdb 20000413 compile problem and strange SEGV...: >Andrew Cagney wrote: >> >> By ``object'' did you mean a warning or an error? >> >> > I downloaded gdb+dejagnu-20000413.tar.bz2 and encountered one problem building >> > it with the Compaq compiler: the compiler objected to comparisons between >> > {current,debug}_target.to_rcmd and tcomplain (which was being case to (void >> > *)). I'm not sure why the cast to (void *) is there at all, but my first >> > thought was to try casting tcomplain to be a pointer to a function, >> > and that worked. This is the patch I used: >> >> Your change makes sense. It was cast to (void*) since the functions >> to_rcmd() and tcomplain() were not type incompatible. The compaq >> compiler is more picky about such things. > >FYI, > >I've just checked and GDB-5.0 build on an ``OSF1 V4.0 464 alpha'' using >both GCC and the native CC. I'll assume that these were compiler >warnings rather than fatal compiler errors. Consequently the cleanups >should get merged into the trunk but not the GDB-5.0 branch. Andrew- Thanks for looking into this. They were errors, not warnings. The build stopped at that point. This was with the latest version of the vendor compiler on alpha-dec-osf4.0f (4.0f == Rev 1229, you can tell what the letter version is by running `sizer -v'). I don't know if I tried this on my 5.0 box at home, but I don't think so. I think rev 464 is osf4.0b, which has a compiler that may not be as recent as the current patched compiler on the later versions of the OS. If you want to email me how I can get access to the 5.0 tree, I'll happily test the build on a few different versions of the OS, including my 5.x box at home. If I just do a `cvs checkout' will I get the 5.0 tree, or do I have to do something special? Tim -- Tim Mooney mooney@dogbert.cc.ndsu.NoDak.edu Information Technology Services (701) 231-1076 (Voice) Room 242-J1, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164