From mboxrd@z Thu Jan 1 00:00:00 1970 From: jtc@redback.com (J.T. Conklin) To: Andrew Cagney Cc: GDB Patches Subject: Re: RFA: Deprecate remote protocol sequence-ID Date: Fri, 24 Mar 2000 14:02:00 -0000 Message-id: <5mln38vxf8.fsf@jtc.redbacknetworks.com> References: <38DAF122.3CA0E862@cygnus.com> X-SW-Source: 2000-03/msg00563.html >>>>> "Andrew" == Andrew Cagney writes: Andrew> I'd like to put forward the proposal that the sequence-id: Andrew> $sequence-id:packet-data#checksum Andrew> Andrew> be clearly deprecated. GDB doesn't produce them and all known targets Andrew> do nothing useful with them. Further, the syntax is dangerous as it Andrew> restricts (in a very bizare way) the contents of actual packets. I agree that we can mark it deprecated, but I'm not sure doing so affords us any more freedom wrt. packet contents. There are deployed debug stubs which can not be updated that will interpret packets with buf[2] == ':' as having a sequence numbers. We've been able to avoid such packets so far, is it really that onerous of a restriction? --jtc -- J.T. Conklin RedBack Networks >From jtc@redback.com Fri Mar 24 14:04:00 2000 From: jtc@redback.com (J.T. Conklin) To: Andrew Cagney Cc: Steven Johnson , GDB Patches Subject: Re: RFA: Deprecate remote protocol sequence-ID Date: Fri, 24 Mar 2000 14:04:00 -0000 Message-id: <5mhfdwvxcu.fsf@jtc.redbacknetworks.com> References: <38DAF122.3CA0E862@cygnus.com> <38DB0EE5.831CD611@ozemail.com.au> <38DB24AB.7881FFA1@cygnus.com> X-SW-Source: 2000-03/msg00564.html Content-length: 275 >>>>> "Andrew" == Andrew Cagney writes: Andrew> I think a simple reliable separate transport layer is needed. I'd even Andrew> go as far as a new packet wrapper (replacing $...#NN and +-). Here, here! --jtc -- J.T. Conklin RedBack Networks >From msnyder@cygnus.com Fri Mar 24 14:05:00 2000 From: Michael Snyder To: John Wehle Cc: cgf@cygnus.com, nsd@cygnus.com, eliz@delorie.com, jimb@cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: GDB 4.17 Patch for stack aligned i386 code Date: Fri, 24 Mar 2000 14:05:00 -0000 Message-id: <38DBE6AF.4A7B@cygnus.com> References: <200003242200.RAA13376@jwlab.FEITH.COM> X-SW-Source: 2000-03/msg00565.html Content-length: 4117 John, Eli, Jim et al, Nick Duffek also recently did some work related to frameless function backtraces on the X86. I don't know whether his work is checked into the main trunk. I'd like to see him involved in this discussion, so that we don't wind up with two solutions to the same problem. Thanks, Michael John Wehle wrote: > > > Is it possible to tell a bit more about the problem, and how is it > > solved? > > It's desirable to omit the frame pointer when compiling leaf functions > when targeting the x86 processor as this provides another hard register > (%ebp) which can be used by the register allocators. Using > -momit-leaf-frame-pointer instructs GCC to compile code in this manner. > Unfortunately GDB has a rather strong belief that %ebp always points to > the frame and is unable to locate function arguments or local variables > when the frame pointer is omitted. The changes allow GDB to locate the > frame based on the value in %esp. > > > Perhaps even a short test case, before and after the change? > > An example is backtracing through sigtramps on Solaris (the Solaris library > contains functions which don't use %ebp as the frame pointer). For example > ... the backtrace from gdb.base/a1-selftest.exp (without my patch) shows: > > #0 0x80068745 in _libc_sigprocmask () > #1 0x80098763 in sigprocmask () > #2 0x8107cb3 in rl_signal_handler (sig=134509072) at signals.c:156 > #3 0x800685b1 in _sigacthandler () > #4 > #5 0x800682b8 in _libc_read () > #6 0x8101ef9 in rl_getc (stream=0x800a9ad4) at readline.c:3123 > #7 0x80ffa5b in rl_read_key () at readline.c:578 > > The correct backtrace is: > > #0 0x80068745 in _libc_sigprocmask () > #1 0x80098763 in sigprocmask () > #2 0x8107fe7 in rl_signal_handler (sig=134509096) at signals.c:156 > #3 0x800685b1 in _sigacthandler () > #4 > #5 0x800682b8 in _libc_read () > #6 0x80098b33 in read () > #7 0x810222d in rl_getc (stream=0x81639a0) at readline.c:3123 > #8 0x80ffd8f in rl_read_key () at readline.c:578 > > > Also, do the original problems affect Solaris alone, or are they > > common to all gcc/x86-based architectures? > > They're common to all gcc/x86-based architectures. > > > It's quite difficult to judge a large patch for two different problems > > without having a more-or-less clear notion of the issues involved. > > Actually they're slight variations of same problem which is how to locate > the frame. The GDB patch in question supports locating the frame for x86 > code: > > 1) In a leaf function where the frame pointer has been omitted. GCC > currently supports generating this if -momit-leaf-frame-pointer is > specified. It's desirable to make this the default once debugging > support is in place. > > 2) In a function where the frame pointer has been omitted and the stack > pointer is unchanging. For example: > > int global; > > void > unchanging_sp(int a, int b) > { > > global = a + b; > print_global(); > } > > I have a patch for GCC to support omitting the frame pointer in this > case which has been delayed pending debugger support. It's desirable > to also have this as part of the default x86 code generation strategy. > > 3) In a function where "andl" has been used to align the frame. I have > an experimental patch for GCC to support aligning the frame in this > fashion in order to improve x86 floating point performance. > > The original GDB work was done in November 1998 and January 1999. I'd be > happy to dust things off on my side in order to get these changes installed > if you're interested in working with me. BTW, the necessary paperwork > is already on file. > > -- John > ------------------------------------------------------------------------- > | Feith Systems | Voice: 1-215-646-8000 | Email: john@feith.com | > | John Wehle | Fax: 1-215-540-5495 | | > ------------------------------------------------------------------------- >From jtc@redback.com Fri Mar 24 14:24:00 2000 From: jtc@redback.com (J.T. Conklin) To: Andrew Cagney Cc: gdb-patches@sourceware.cygnus.com Subject: Re: RFA: USE_STRUCT_CONVENTION for NetBSD/i386 Date: Fri, 24 Mar 2000 14:24:00 -0000 Message-id: <5md7okvwfx.fsf@jtc.redbacknetworks.com> References: <5msnxieegg.fsf@jtc.redbacknetworks.com> <38DAD990.D91D6D1B@cygnus.com> X-SW-Source: 2000-03/msg00566.html Content-length: 1360 >>>>> "Andrew" == Andrew Cagney writes: >> ! int >> ! i386nbsd_use_struct_convention (int gcc_p, struct type *type) >> ! { >> ! return !(TYPE_LENGTH (type) == 1 >> ! || TYPE_LENGTH (type) == 2 >> ! || TYPE_LENGTH (type) == 4 >> ! || TYPE_LENGTH (type) == 8); >> ! } >> ! Andrew> I'd add a FIXME pointing out known problems with the function. Andrew> Otherwize ok. It's not i386nbsd_use_struct_convention() that needs a FIXME, as it now properly identifies all functions which return structures via a hidden pointer vs. those which return structures via registers. It's i386_extract_return_type() which doesn't know that structures with a single float or double field are returned in floating point registers. Andrew> I assume Mark is trying to figure out why NetBSD can't simply Andrew> use a common i386_use_struct_convention function. I take it Andrew> from your answer, that NetBSD's convention isn't 100% standard Andrew> (where standard would mean what someone other than Linux or Andrew> *BSD did. Solaris/x86?). I don't think NetBSD does anything non-standard other than defining DEFAULT_PCC_STRUCT_RETURN to 0 in its gcc config. So this behavior should be shared among all x86 targets that do the same: cygwin, freebsd, linux-aout, and mach. --jtc -- J.T. Conklin RedBack Networks >From jtc@redback.com Fri Mar 24 14:44:00 2000 From: jtc@redback.com (J.T. Conklin) To: "Philippe De Muyter" Cc: gdb-patches@sourceware.cygnus.com (gdb-patches@sourceware.cygnus.com), dan@cgsoftware.com Subject: Re: regerror link error Date: Fri, 24 Mar 2000 14:44:00 -0000 Message-id: <5m8zz8vviv.fsf@jtc.redbacknetworks.com> References: <200003242151.WAA07612@mail.macqel.be> X-SW-Source: 2000-03/msg00567.html Content-length: 619 >>>>> "Philippe" == Philippe De Muyter writes: Philippe> makes the compilation of gdb fail on my system (m68k-motorola-sysv) : Philippe> [...] Philippe> Actually, I have found a __regerror, but no regerror. How Philippe> can we fix that ? I think the __regerror() function in gnu-regex.c needs to be renamed regerror(). All the other functions in that file are defined without leading double-underscores with a weak_alias() which I assume maps the two forms together in glibc. It certainly looks like the underscores aren't supposed to be there. --jtc -- J.T. Conklin RedBack Networks >From nsd@cygnus.com Fri Mar 24 14:45:00 2000 From: nsd@cygnus.com To: msnyder@cygnus.com Cc: cgf@cygnus.com, eliz@delorie.com, gdb-patches@sourceware.cygnus.com, jimb@cygnus.com, john@feith.com Subject: Re: GDB 4.17 Patch for stack aligned i386 code Date: Fri, 24 Mar 2000 14:45:00 -0000 Message-id: <200003242245.WAA07630@nog.bosbc.com> References: <38DBE6AF.4A7B@cygnus.com> X-SW-Source: 2000-03/msg00568.html Content-length: 780 >Nick Duffek also recently did some work related to frameless >function backtraces on the X86. Yup. >I don't know whether his >work is checked into the main trunk. Nope. I wanted to tighten up a couple things before committing the changes. >I'd like to see him >involved in this discussion, so that we don't wind up with >two solutions to the same problem. Thanks for the heads-up. >> It's desirable to omit the frame pointer when compiling leaf functions >> when targeting the x86 processor as this provides another hard register >> (%ebp) which can be used by the register allocators. The code I wrote handles non-leaf functions too. It only works on x86 at the moment, but I tried to make it architecture-independent. I'll try to post my patches this weekend. Nick >From jimb@zwingli.cygnus.com Fri Mar 24 15:26:00 2000 From: Jim Blandy To: gdb-patches@sourceware.cygnus.com Subject: RFA: handle sparse register sets in Insight register window Date: Fri, 24 Mar 2000 15:26:00 -0000 Message-id: <200003242326.SAA17809@zwingli.cygnus.com> X-SW-Source: 2000-03/msg00569.html Content-length: 5252 The Insight register window doesn't properly display register sets that have holes in the register numbering. Jim Ingham's change of 1999-10-05 doesn't fix the whole problem. In gdb/gdbtk/generic/ChangeLog-gdbtk: 2000-03-24 Jim Blandy Handle the fact that there are holes in the register numbering. (gdb_regnames): Return value is now a list of pairs of the form {REGNAME NUMBER}. (get_register_name): Record both the register name and number. In gdb/gdbtk/library/ChangeLog: 2000-03-24 Jim Blandy Handle the fact that there are holes in the register numbering. * actiondlg.tcl (ActionDlg::constructor): Handle new type of gdb_regnames result. * regwin.itb (RegWin::init_reg_display_vars, RegWin::build_win): Same. Use the register numbers provided by gdb_regnames; don't just assume that the Nth element is register N. Index: gdb/gdbtk/generic/gdbtk-cmds.c =================================================================== RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk-cmds.c,v retrieving revision 1.4 diff -c -r1.4 gdbtk-cmds.c *** gdb/gdbtk/generic/gdbtk-cmds.c 2000/02/29 22:47:37 1.4 --- gdb/gdbtk/generic/gdbtk-cmds.c 2000/03/24 23:19:55 *************** *** 1834,1840 **** } /* This implements the TCL command `gdb_regnames', which returns a list of ! all of the register names. */ static int gdb_regnames (clientData, interp, objc, objv) --- 1834,1840 ---- } /* This implements the TCL command `gdb_regnames', which returns a list of ! all of the register names, and their indices. */ static int gdb_regnames (clientData, interp, objc, objv) *************** *** 1854,1861 **** int regnum; void *argp; /* Ignored */ { ! Tcl_ListObjAppendElement (NULL, result_ptr->obj_ptr, ! Tcl_NewStringObj (REGISTER_NAME (regnum), -1)); } /* This implements the tcl command gdb_fetch_registers --- 1854,1869 ---- int regnum; void *argp; /* Ignored */ { ! /* Build a tuple of the form "{REGNAME NUMBER}", and append it to ! our result. */ ! Tcl_Obj *array[2]; ! Tcl_Obj *pair; ! ! array[0] = Tcl_NewStringObj (REGISTER_NAME (regnum), -1); ! array[1] = Tcl_NewIntObj (regnum); ! pair = Tcl_NewListObj (2, array); ! ! Tcl_ListObjAppendElement (NULL, result_ptr->obj_ptr, pair); } /* This implements the tcl command gdb_fetch_registers Index: gdb/gdbtk/library/actiondlg.tcl =================================================================== RCS file: /cvs/src/src/gdb/gdbtk/library/actiondlg.tcl,v retrieving revision 1.1.1.1 diff -c -r1.1.1.1 actiondlg.tcl *** gdb/gdbtk/library/actiondlg.tcl 2000/02/07 00:19:42 1.1.1.1 --- gdb/gdbtk/library/actiondlg.tcl 2000/03/24 23:20:00 *************** *** 30,36 **** set top [winfo toplevel [namespace tail $this]] wm withdraw $top ! set Registers [gdb_regnames] if {$Line != ""} { set Locals [gdb_get_locals "$File:$Line"] set Args [gdb_get_args "$File:$Line"] --- 30,40 ---- set top [winfo toplevel [namespace tail $this]] wm withdraw $top ! set Registers {} ! set tmp [gdb_regnames] ! foreach pair $tmp { ! lappend Registers [lindex $pair 0] ! } if {$Line != ""} { set Locals [gdb_get_locals "$File:$Line"] set Args [gdb_get_args "$File:$Line"] Index: gdb/gdbtk/library/regwin.itb =================================================================== RCS file: /cvs/src/src/gdb/gdbtk/library/regwin.itb,v retrieving revision 1.1.1.1 diff -c -r1.1.1.1 regwin.itb *** gdb/gdbtk/library/regwin.itb 2000/02/07 00:19:42 1.1.1.1 --- gdb/gdbtk/library/regwin.itb 2000/03/24 23:20:01 *************** *** 77,83 **** set regMaxLen 0 foreach r [gdb_regnames] { ! set l [string length $r] if {$l > $regMaxLen} { set regMaxLen $l } --- 77,83 ---- set regMaxLen 0 foreach r [gdb_regnames] { ! set l [string length [lindex $r 0]] if {$l > $regMaxLen} { set regMaxLen $l } *************** *** 187,206 **** set reg_display_list {} set regnames [gdb_regnames] set i 1 - set rn 0 foreach r $regnames { ! set reg_display($rn,name) $r ! set format [pref getd gdb/reg/$r-format] if {$format == ""} { set format x } set reg_display($rn,format) $format ! if {$args != "" && [pref getd gdb/reg/$r] == "no"} { set reg_display($rn,line) 0 } else { set reg_display($rn,line) $i lappend reg_display_list $rn incr i } - incr rn } set num_regs [expr {$i - 1}] set max_regs $rn --- 187,206 ---- set reg_display_list {} set regnames [gdb_regnames] set i 1 foreach r $regnames { ! set name [lindex $r 0] ! set rn [lindex $r 1] ! set reg_display($rn,name) $name ! set format [pref getd gdb/reg/$name-format] if {$format == ""} { set format x } set reg_display($rn,format) $format ! if {$args != "" && [pref getd gdb/reg/$name] == "no"} { set reg_display($rn,line) 0 } else { set reg_display($rn,line) $i lappend reg_display_list $rn incr i } } set num_regs [expr {$i - 1}] set max_regs $rn >From jimb@zwingli.cygnus.com Fri Mar 24 15:45:00 2000 From: Jim Blandy To: Michael Snyder Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH]: swat a warning in solib.c Date: Fri, 24 Mar 2000 15:45:00 -0000 Message-id: References: <200003240048.QAA20906@cleaver.cygnus.com> X-SW-Source: 2000-03/msg00570.html Content-length: 260 > A common trick when using catch_errors is to pass an int argument > as a void* by casting it. This generates warnings (if nothing else!) > when int and void* are not the same size. Instead let's pass the > address of the int. Thanks. Please commit this. >From john@feith.com Fri Mar 24 15:55:00 2000 From: John Wehle To: nsd@bosbc.com Cc: cgf@cygnus.com, eliz@delorie.com, gdb-patches@sourceware.cygnus.com, jimb@cygnus.com, msnyder@cygnus.com Subject: Re: GDB 4.17 Patch for stack aligned i386 code Date: Fri, 24 Mar 2000 15:55:00 -0000 Message-id: <200003242355.SAA14221@jwlab.FEITH.COM> X-SW-Source: 2000-03/msg00571.html Content-length: 966 >>> It's desirable to omit the frame pointer when compiling leaf functions >>> when targeting the x86 processor as this provides another hard register >>> (%ebp) which can be used by the register allocators. > > The code I wrote handles non-leaf functions too. It only works on x86 at > the moment, but I tried to make it architecture-independent. I only handle non-leaf functions if the stack pointer is unchanging (i.e. there are no arguments placed on the stack of the function being called). Are you handling non-leaf functions even when the stack pointer is changing? Does your patch handle functions where the prologue uses "andl" to align the frame? -- John ------------------------------------------------------------------------- | Feith Systems | Voice: 1-215-646-8000 | Email: john@feith.com | | John Wehle | Fax: 1-215-540-5495 | | ------------------------------------------------------------------------- From mboxrd@z Thu Jan 1 00:00:00 1970 From: jtc@redback.com (J.T. Conklin) To: Andrew Cagney Cc: GDB Patches Subject: Re: RFA: Deprecate remote protocol sequence-ID Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-ID: <5mln38vxf8.fsf@jtc.redbacknetworks.com> References: <38DAF122.3CA0E862@cygnus.com> X-SW-Source: 2000-q1/msg01002.html Message-ID: <20000401000000.OibhKfdNSvWPT_R22trjudNK3MV6biEW6BJvC8jdVGg@z> >>>>> "Andrew" == Andrew Cagney writes: Andrew> I'd like to put forward the proposal that the sequence-id: Andrew> $sequence-id:packet-data#checksum Andrew> Andrew> be clearly deprecated. GDB doesn't produce them and all known targets Andrew> do nothing useful with them. Further, the syntax is dangerous as it Andrew> restricts (in a very bizare way) the contents of actual packets. I agree that we can mark it deprecated, but I'm not sure doing so affords us any more freedom wrt. packet contents. There are deployed debug stubs which can not be updated that will interpret packets with buf[2] == ':' as having a sequence numbers. We've been able to avoid such packets so far, is it really that onerous of a restriction? --jtc -- J.T. Conklin RedBack Networks >From eliz@delorie.com Sat Apr 01 00:00:00 2000 From: Eli Zaretskii To: ac131313@cygnus.com Cc: gdb-patches@sourceware.cygnus.com Subject: Re: GDB-5 2000-03-03 Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003040702.CAA08162@indy.delorie.com> References: <38BFBD74.79263683@cygnus.com> X-SW-Source: 2000-q1/msg00500.html Content-length: 1348 > http://sourceware.cygnus.com/gdb/issues50.html > > Hello, > > I've appended a copy of the above page. This doesn't include the watchpoint-related patches I sent beginning with August or September, and mentioned them again three weeks ago. Here again are the pointers to the relevant messages: http://sourceware.cygnus.com/ml/gdb-patches/1999-q3/msg00173.html http://sourceware.cygnus.com/ml/gdb-patches/1999-q3/msg00204.html http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00200.html http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00201.html > In the case of ELi's binutils stuff, something more ruthless might be > needed. I don't think this is needed anymore, since Ian merged in some of my changes and the rest are solved by upgrading to a later libtool. (I still have some unprocessed Binutils patches, but they are not important for GDB, since they are in the applications, like ld and ar, not in the libraries.) But there's a similar issue with Readline. The current version in the GDB CVS tree has bugs in the DJGPP-specific code, one of which simply prevents GDB from linking. I see that most of these problems are solved in the current beta version of Readline, but will you be synchronizing the GDB tree with that version before release? If not, I don't see any solution but a local patch. Please advise. >From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000 From: Mark Kettenis To: eliz@delorie.com Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH]: DJGPP build and cleanup Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200002232247.e1NMljJ28359@delius.kettenis.local> References: <200002232229.RAA18809@indy.delorie.com> X-SW-Source: 2000-q1/msg00345.html Content-length: 938 Date: Wed, 23 Feb 2000 17:29:16 -0500 (EST) From: Eli Zaretskii The change to i386-tdep.c should probably be approved by someone (I cannot figure out from MAINTAINERS who's responsible for i386 targets). Youd didn't include the changes to i386-tdep.c :-(. Anyway, I don't think the I386_DJGPP_TARGET define doesn't seem the right approach, although I don't blame you for using it, since somebody set a bad example. I just want to take the opportunity to bring something under the attention of the i386 hackers again. The point is that if you look at the GCC configuration files, you'll see that returning FP values in the FP registers is the default for most (probably all) i386 targets. So I think this should be the default in GDB too. And even if people are opposed to making this the default, we should make it depend on a feature macro, and not on a list of target identifying macro's. Mark >From jtc@redback.com Sat Apr 01 00:00:00 2000 From: jtc@redback.com (J.T. Conklin) To: Mark Kettenis Cc: gdb-patches@sourceware.cygnus.com Subject: Re: RFA: USE_STRUCT_CONVENTION for NetBSD/i386 Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <5mitye7b2s.fsf@jtc.redbacknetworks.com> References: <5msnxieegg.fsf@jtc.redbacknetworks.com> <200003230032.e2N0WuD00374@delius.kettenis.local> X-SW-Source: 2000-q1/msg00929.html Content-length: 687 >>>>> "Mark" == Mark Kettenis writes: Mark> Problems remain with functions returning structs of these two forms: Mark> Mark> struct one_float_t { Mark> float x; Mark> }; Mark> Mark> struct one_double_t { Mark> double x; Mark> }; Mark> Mark> Could you elaborate on that? What is the convention used by NetBSD Mark> for returning those structs and why does GDB fail? Gcc, at least gcc-2.95.2, returns the above structs in floating point registers instead of integer registers. I don't think NetBSD's gcc config does anything special except for setting DEFAULT_PPC_STRUCT_RETURN to 0. --jtc -- J.T. Conklin RedBack Networks >From kevinb@cygnus.com Sat Apr 01 00:00:00 2000 From: Kevin Buettner To: Jim Blandy , gdb-patches@sourceware.cygnus.com Subject: Re: Linux sigtramp detection code moved to its proper place Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <1000316225504.ZM3009@ocotillo.lan> References: <200003162241.RAA19616@zwingli.cygnus.com> X-SW-Source: 2000-q1/msg00749.html Content-length: 397 On Mar 16, 5:41pm, Jim Blandy wrote: > There's a lot of code in i386-tdep.c devoted to identifying and > unraveling Linux signal trampolines. There's absolutely no reason I > can think of that this should be in i386-tdep.c, intead of > i386-linux-nat.c. I think it should go in i386-linux-tdep.c instead. That way you'd be able to debug a linux/ia32 target from a non-linux/ia32 host. Kevin >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: Philippe De Muyter Cc: "gdb-patches@sourceware.cygnus.com" Subject: Re: PATCH/RFA: regerror link error Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38DFFFF1.A2BD1D4E@cygnus.com> References: <200003271122.NAA25753@mail.macqel.be> X-SW-Source: 2000-q1/msg01072.html Content-length: 558 Philippe De Muyter wrote: > Mon Mar 27 12:23:37 2000 Philippe De Muyter > > * gnu-regex.c (regerror): Function renamed from `__regerror'. The change is fine. It's already in the official glibc. Would you be able to hunt up the original ChangeLog entry from glibc and include that as part of your ChangeLog or, failing that, at least note that the change has been approved in the mainline sources. That way the poor soul that gets to import the next regexp.c knows that that local change was merged back in. enjoy, Andrew >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: Chris Faylor Cc: gdb-patches@sourceware.cygnus.com, Fernando Nasser Subject: Re: Add support for WinCE toolchains Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38B376E2.6ABAE68D@cygnus.com> References: <200002222350.PAA09035@elmo.cygnus.com> <200002230024.TAA11216@envy.delorie.com> <38B32E01.34616D70@apple.com> <88vbe5$4r5$1@cronkite.cygnus.com> <88vrpb$bs1$1@cronkite.cygnus.com> X-SW-Source: 2000-q1/msg00327.html Content-length: 1238 Chris Faylor wrote: > > In article < 88vbe5$4r5$1@cronkite.cygnus.com >, > Chris Faylor wrote: > >One of the things I've done is to regularize the name of files that I > >used. Everything has a "wince" in it now since the WinCE version of PE > >is apparently non-standard. I've also moved WinCE-specific code out of > >the generic target files into their own files. > > Here is an addition/modification to what Nick Clifton had previously > proposed. Most of the files are the same with the exception of > configure.tgt and the addition of some new target files in the > appropriate directories. Per Andrew's request, there are no > modifications to any other files in config/*. > > cgf > > 2000-02-23 Christopher Faylor > > * configure.tgt: Add arm, mips, sh wince targets. > * config/arm/tm-wince.h: New file. > * config/arm/wince.mt New file. > * config/sh/tm-wince.h: New file. > * config/sh/wince.mt New file. > * config/mips/tm-wince.h: New file. > * config/mips/wince.mt New file. The configury plus config/sh and config/mips stuff are both ok with me. I'm 99% sure that the config/arm stuff would be ok with Fernando. Andrew >From msnyder@cygnus.com Sat Apr 01 00:00:00 2000 From: msnyder@cygnus.com To: cagney@cygnus.com, gdb-patches@sourceware.cygnus.com Subject: [PATCH]: swat warning in ui-file.c Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003240143.RAA21777@seadog.cygnus.com> X-SW-Source: 2000-q1/msg00964.html Content-length: 1104 Including gdb_string.h eliminates a warning on sparc64. 2000-03-23 Michael Snyder * ui-file.c: include "gdb_string.h" Index: ChangeLog =================================================================== RCS file: /cvs/src/src/gdb/ChangeLog,v retrieving revision 1.170 diff -c -r1.170 ChangeLog *** ChangeLog 2000/03/23 23:43:19 1.170 --- ChangeLog 2000/03/24 01:42:33 *************** *** 1,3 **** --- 1,7 ---- + 2000-03-23 Michael Snyder + + * ui-file.c: include "gdb_string.h" + 2000-03-23 Fernando Nasser From David Whedon Index: ui-file.c =================================================================== RCS file: /cvs/src/src/gdb/ui-file.c,v retrieving revision 1.1.1.1 diff -c -r1.1.1.1 ui-file.c *** ui-file.c 2000/02/02 00:21:11 1.1.1.1 --- ui-file.c 2000/03/24 01:42:33 *************** *** 22,27 **** --- 22,28 ---- #include "defs.h" #include "ui-file.h" + #include "gdb_string.h" #undef XMALLOC #define XMALLOC(TYPE) ((TYPE*) xmalloc (sizeof (TYPE))) >From toddpw@windriver.com Sat Apr 01 00:00:00 2000 From: Todd Whitesel To: kingdon@redhat.com (Jim Kingdon) Cc: akale@veritas.com, kettenis@wins.uva.nl, gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: Regression caused by elfread.c patch Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200002150800.AAA07477@alabama.wrs.com> References: <200002150453.XAA11268@devserv.devel.redhat.com> X-SW-Source: 2000-q1/msg00151.html Content-length: 1928 > I don't see how your patch could work at all - sym->section->index is > a very different number than a SECT_OFF_* code. The SECT_OFF_* code In case it interests anyone, I spent most of January figuring out how to teach GDB how to let both cases coexist properly. It is my considered opinion that the SECT_OFF_* machinery really only works when all the offsets are the same. However, so few configurations (read: vxWorks and ??) actually use different offsets for, say, SECT_OFF_TEXT and SECT_OFF_DATA, that no one notices the problems with it. (We read relocatable .o files too, which is also rare.) Our particular bug is as follows: for a.out, read-only data gets put into .text, but the stabs generated are indistinguishable (or prohibitively hard to distinguish, anyway) from a non-const version of the same item which gets put into .data. Thus it is impossible to find the correct address without using actual relocation records. (The same bug occurs on ELF although in this case it is because .rodata is classed as a text section by our loader, which then feeds us a single address for the group of text sections. sigh) One of our consultants developed code for ELF/DWARF relocatables which actually calls bfd_final_link_relocate to process reloc info, because in the DWARF case we have even less information to tell things apart than with stabs. I extended that to do full final address relocation and worked out how to have struct section_offsets keep track of what is going on, so that ANOFFSET can be replaced with a variety of different macros depending on what usage is intended. (This also allowed optional asserts to be compiled in, which turned out to be helpful once I started testing, and illuminated a few cases too.) A gutted tarball of 4.17+local sources is temporarily available (in an execute-only directory) at: ftp://ftp.toddpw.org/private/vxgdb.tar.bz2 -- Todd Whitesel toddpw @ windriver.com >From grante@visi.com Sat Apr 01 00:00:00 2000 From: Grant Edwards To: Fernando Nasser Cc: gdb-patches@sourceware.cygnus.com Subject: Re: Patch for RDI target code to allow user-specified devices Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <20000221223021.A12670@visi.com> References: <20000221141155.A31206@visi.com> <38B1C28D.50BC5918@cygnus.com> X-SW-Source: 2000-q1/msg00299.html Content-length: 3463 On Mon, Feb 21, 2000 at 05:56:13PM -0500, Fernando Nasser wrote: > > The current routines limit the user to a certain set of devices > > (which never seems to include the one I want). I've tripped > > over this many times. With the patch applied, the target > > commands like > > > > target rdi s=/whatever/flipping/device/the/user/wants > > target rdi s=/serial/device/name,p=/parallel/device/name > > > > Will accept whatever the user specifies (I think the path is > > limited to 64 characters). After all it's _my_ computer and I > > do, in fact, know which serial port is hooked to the target! > > The fact that the ARM Ltd. code won't believe me has always > > been annoying... > > So far so good. > > However, people also like to specify: > > target rdi /dev/ttyS0 > and let gdb figure this is a serial device (the same applies to a > parallel device). When you cut the "if" you cut it too short, and > now one is required to specify the "s:" or "p:". Oops. I only intended to change the behavior when you specified s= or p=, the behavior when you just specified a device name wasn't supposed to change. Thanks for catching that. > If you put that back I think it is fine. You should be able to have > a different device name, as long as you let gdb know if it is a > serial "s:" or parallel "p:" device -- it is the price you pay (but > we cannot impose this on the ones with standard names, right?) Sure -- that's what I had intended. > > Yes, I know, the patched code uses a different indenting style > > that the rest of the file -- if this is a problem, feel free to > > re-indent it however you please. I simply can not easily grok > > the existing style. > Now we really got to a crossroads here. I believe the reason people > were leaving the indentation alone was because we could eventually > receive a newer code from ARM and having their indentation would > help scanning for the differences. We have already changed this > code a lot, and they probably did the same, so a diff would probably > be useless. I don't know if ARM is maintaining this code or not. > We could discuss with the other interested parts a move (moving to > gdb@sourceware) a possible GNU style reindentations of the whole > rdi-share directory. This would take time. It doesn't really matter much to me. I have a hard time reading code indented in the sytle of the original ARM code, but when I'm done messing with it, I can re-indent it to match the rest of the file. > I could eventually reindent it myself, but with the size of my > current todo list this will take even longer :-) Mixing the two > indentation styles gives me the creeps. I don't know what Stan and > Andrew think about this but I would guess they may also object. Rightly so. > The fastest way to get you patch in would be for you to keep the > current indentation. In the meanwhile you could propose a GNU > reindentation of the whole thing to gdb@sourceware. I'll fix the "if" problem and re-indent it to match the rest of the file. > But don't worry about the possible differences from 4.18 sources > with or without patches. I will take care of adjusting that for > you. So far the patches haven't overlapped, so it shouldn't be a bit deal. One of these days I'm going to try to figure out why the current snapshot isn't working for me. BTW, the parallel port code does seem to work, in case anybody was wondering. :) -- Grant Edwards grante@visi.com >From Peter.Schauer@regent.e-technik.tu-muenchen.de Sat Apr 01 00:00:00 2000 From: "Peter.Schauer" To: gdb-patches@sourceware.cygnus.com Subject: RFA: procfs.c:proc_set_watchpoint bug fix Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003072114.WAA26143@reisser.regent.e-technik.tu-muenchen.de> X-SW-Source: 2000-q1/msg00556.html Content-length: 925 procfs.c:proc_set_watchpoint currently declares its addr parameter as void *, but it is called from procfs_set_watchpoint with a CORE_ADDR addr. This causes problems if sizeof(CORE_ADDR) > sizeof(void *), e.g on Solaris 2.7 sparc. Here is a fix: 2000-03-07 Peter Schauer * procfs.c (proc_set_watchpoint): Declare addr parameter as CORE_ADDR, to match call from procfs_set_watchpoint. *** gdb/procfs.c.orig Wed Mar 1 21:54:05 2000 --- gdb/procfs.c Sun Mar 5 12:05:33 2000 *************** *** 2580,2586 **** int proc_set_watchpoint (pi, addr, len, wflags) procinfo *pi; ! void *addr; int len; int wflags; { --- 2580,2586 ---- int proc_set_watchpoint (pi, addr, len, wflags) procinfo *pi; ! CORE_ADDR addr; int len; int wflags; { -- Peter Schauer pes@regent.e-technik.tu-muenchen.de >From ezannoni@cygnus.com Sat Apr 01 00:00:00 2000 From: Elena Zannoni To: Andrew Cagney Cc: Eli Zaretskii , gdb-patches@sourceware.cygnus.com Subject: Re: GDB-5 2000-03-03 Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <14531.54961.880860.662139@kwikemart.cygnus.com> References: <38BFBD74.79263683@cygnus.com> <200003040702.CAA08162@indy.delorie.com> <38C0E240.FC02154E@cygnus.com> X-SW-Source: 2000-q1/msg00531.html Content-length: 948 Andrew Cagney writes: > Eli Zaretskii wrote: > > > But there's a similar issue with Readline. The current version in the > > GDB CVS tree has bugs in the DJGPP-specific code, one of which simply > > prevents GDB from linking. I see that most of these problems are > > solved in the current beta version of Readline, but will you be > > synchronizing the GDB tree with that version before release? If not, > > I don't see any solution but a local patch. Please advise. > > Consider yourself the maintainer of the DJGPP specific readline stuff > (like mmalloc). (I'll add a note to MAINTAINERS.) > > The main thing is to make certain that the true readline sources have > the fix as well. I wasn't planning on importing readline (I'll add a > note stateing that this is something that won't make it). > > Andrew Eli, yes, please check in you fix to readline, I have no time this week to do another import. Thanks Elena >From dima@Chg.RU Sat Apr 01 00:00:00 2000 From: Dmitry Sivachenko To: gdb-patches@sourceware.cygnus.com Subject: problem with gdb.texinfo Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003231748.UAA57854@netserv1.chg.ru> X-SW-Source: 2000-q1/msg00939.html Content-length: 229 Hello! It seems that last commit to gdb.texinfo (which lead to rev. 1.4) broke building of info-file. Now makeinfo reports: Too many columns in multitable item (max 3). Probable it is necessary to back out this commit. --dima >From donnte@microsoft.com Sat Apr 01 00:00:00 2000 From: Donn Terry To: 'Philippe De Muyter' , ac131313@cygnus.com Cc: ezannoni@cygnus.com, gdb-patches@sourceware.cygnus.com Subject: RE: HAVE_POLL is not enough Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: X-SW-Source: 2000-q1/msg00447.html Content-length: 3838 I'm in a similar boat, except that: Only poll() works some places (/proc). Only select() works other places (pty/tty). (This is a consequence of a "step in the right direction", but the 2d step hasn't happened yet.) Writing the /proc stuff to dynamically switch would be a pain (at best). The test really belongs in configure, but lacking that it probably belongs in the manually configured header files. (Something along the lines of (for the default): #ifdef HAVE_POLL #define USE_POLL_ON_PROC #define USE_POLL_ON_TTY #else #undef USE_POLL_ON_PROC #undef USE_POLL_ON_TTY #endif For special cases (using mine as an example): #undef USE_POLL_ON_TTY #undef USE_POLL_ON_PROC // Just for error prevention #define USE_POLL_ON_PROC Donn Terry Speaking only for myself, of course. > -----Original Message----- > From: Philippe De Muyter [ mailto:phdm@macqel.be ] > Sent: None > To: ac131313@cygnus.com > Cc: ezannoni@cygnus.com; gdb-patches@sourceware.cygnus.com > Subject: Re: HAVE_POLL is not enough > > > First of all, sorry for the long delay for answers, but I am > really busy > (and more) with my day-hours work. > > > Elena Zannoni wrote: > > > > > > Philippe De Muyter writes: > > > > With the gdb cvs tree of 2000-02-19, on > m68k-motorola-sys, configure > > > > correctly detect that we have `poll', but gdb > incorrectly assumes that > > > > `poll' can be used to wait for `stdin'. On > m68k-motorola-sysv, tty's > > > > are not stream-based and not `poll'able. Should the > configure test > > > > be enhanced ? I don't think so if we need to run a > target program to check > > > > that, because it would fail if we cross-compile gdb, > but if it can be > > > > determined by other ways, like the presence of some > constants in some > > > > header files then I would agree. We could also always > compile in the `poll' > > > > version if HAVE_POLL, but switch to the the fall-back > method at run time if > > > > poll fails with POLLNVAL. > > > > > > > > > > Right now the decision on whether to run gdb with or > without the event > > > loop is determined by the user as start up, and it is not detected > > > neither by configure or at run time. The easiest thing to > do for now > > I did not ask explicitly to start gdb with or without the > event-loop, and it > tried automatically to use the event-loop. I don't know why > but that seems > to invalidate Elena's statement that `it is determined by the > user as start up'. > > > > is probably tell the user what happened and switch to > > > non-event-loop mode. Maybe some configury work could be done to > > > determine whether the tty's can be pollable, I am not > familiar with > > > your system enough to know whether this is anything > feasible. Sorry I > > > cannot be of more help here. > > > How about the 'target async' part, would that work? > > > > As far as I know, this problem is still present. > > > > Following on from Elena's comment. Is there any known work > around or > > other hack available? > > > > If we get really desparate there is always the option of putting: > > > > HOST_POLL_BROKEN > > > > in > > > > config/m68k/xm-m68kv4.h > > > > :-( (And yes, I'm about to get really desperate). > > > > Philippe, if GDB is forced to use select, does it work? > > If we never use poll, and always use select if it is > available, I think > we'll then have the inverse problem : platforms where some > channels are > `poll'-able, but not `select'-able. > > So, my idea is : at gdb startup, first poll the needed fd's > one by one with > a null or small timeout, and if one is not `poll'-able, then > switch to `select'. > I know that on m68k-motorola-sysv, `stdin' is `select'-able, > so this scheme > would work. > > Sorry, no time for a patch at the moment. > > > > > Andrew > > > >From jsm@cygnus.com Sat Apr 01 00:00:00 2000 From: Jason Molenda To: "J.T. Conklin" Cc: gdb-patches@sourceware.cygnus.com Subject: Re: patch: convert gdbserver to autoconf, add netbsd/i386 support Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <20000210192010.A12329@cygnus.com> References: <5mn1p88ma8.fsf@jtc.redbacknetworks.com> X-SW-Source: 2000-q1/msg00120.html Content-length: 651 After a brief visual inspection the configury changes look good to me. (not that my opinion is the one that counts :-) On Thu, Feb 10, 2000 at 07:12:47PM -0800, J.T. Conklin wrote: > I used autoconf 2.12 to generate the gdbserver/configure script. If > there's a more official version, feel free to re-generate it. Submitting auto-generated files like this really isn't necessary (it just makes a patch look a whole lot longer than it really is). FWIW autoconf 2.13 is the latest released version; it's the one that should be used to generate any configure files. Thanks for the patch, it's one less use of the old Cygnus configure cruft. Jason >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: Eli Zaretskii Cc: meissner@cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: -Wall -Wno-unused-param Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38DEA2A3.6E683025@cygnus.com> References: <38D9A096.E4FFC223@cygnus.com> <20000323132841.28903@cse.cygnus.com> <38DAC122.D2155F0A@cygnus.com> <200003260242.VAA20607@mescaline.gnu.org> X-SW-Source: 2000-q1/msg01041.html Content-length: 724 Eli Zaretskii wrote: > > With regard to ATTRIBUTE_UNUSED, GDB is sitting at a cross road where > people could either go through and add that everywhere or just require > people to use a state-of-the-art compiler to check for warnings. I like > the latter, its easier overall :-) > > For reasons I'd pefer not to go into here, I (still) don't trust GCC > 2.95.x enough to rely on the latest version of the compiler. > > I've already changed go32-nat.c and ser-go32.c to use ATTRIBUTE_UNUSED > so as to shut up the compiler. YMMV. FYI, I've no intention of requiring people to use that compiler. I'll most likely set up a script that counts up compiler warnings and publishes the results. enjoy, Andrew >From shebs@apple.com Sat Apr 01 00:00:00 2000 From: Stan Shebs To: Eli Zaretskii Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH] GDB command-line switches and annotations docs Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38C94A79.617C23CB@apple.com> References: <200003101347.IAA21898@indy.delorie.com> X-SW-Source: 2000-q1/msg00648.html Content-length: 1215 Eli Zaretskii wrote: > > Here are patches to gdb.texinfo and annotate.texi which add indexing > to command-line switches, document some switches that were not in the > manual, and make annotate.texi part of GDB manual. I only have one suggestion to add to what others have already commented on; this should be positioned after the chapter on using readline, and before all the appendices. As it stands, the TOC might look a bit strange, with a regular chapter after the last appendix and just before the index. Alternatively, it could be an appendix (using @appendix) but appendices seem better for meta-issues like installation, so I'd rather see it be a chapter. (Yes, that suggests that the Using History Interactively appendix should be a chapter instead, which I would like to do too.) Thanks for doing this! I love it when other people do my job... :-) > (Are there plans to make gdbmi.texi be part of the manual as well?) I'd like to see it go in there sooner rather than later too. Otherwise you're introducing discrepancies between the manual and the documentation, and everybody is confused - witness the lack of doc for the tracing commands still, some two years after they were added... Stan >From fnasser@cygnus.com Sat Apr 01 00:00:00 2000 From: Fernando Nasser To: shebs@apple.com Cc: dan@cgsoftware.com, gdb-patches@sourceware.cygnus.com Subject: Re: [RFA]: Apropos patch Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38DA96EE.48083931@cygnus.com> References: <1z52tswd.fsf@dan.resnet.rochester.edu> <38D9815A.FC4E178E@apple.com> <38DA9495.C41B6448@apple.com> X-SW-Source: 2000-q1/msg00949.html Content-length: 362 Approved. Please separate the void from the function definition before committing (is your ssh connection ready?). Thanks again for doing this. -- 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 jtc@redback.com Sat Apr 01 00:00:00 2000 From: jtc@redback.com (J.T. Conklin) To: gdb-patches@sourceware.cygnus.com Subject: RFA: i386/nbsd.mt, i386nbsd-nat.c Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <5m1z54gif1.fsf@jtc.redbacknetworks.com> X-SW-Source: 2000-q1/msg00872.html Content-length: 6708 I submit the enclosed patch for approval. This change splits out NetBSD native support from the FreeBSD, BSDI, and 386BSD support. The changes I submitted earlier today convert the NetBSD target to use the generic floating point register support, which conflicts with i386b-nat.c --jtc 2000-03-21 J.T. Conklin * i386/nbsd.mh (NATDEPFILES): Changed i386b-nat.c to i386nbsd-nat.c. * i386nbsd-nat.c: New file. Index: nbsd.mh =================================================================== RCS file: /cvs/src/src/gdb/config/i386/nbsd.mh,v retrieving revision 1.1.1.1 diff -c -3 -p -r1.1.1.1 nbsd.mh *** nbsd.mh 1999/04/16 01:34:19 1.1.1.1 --- nbsd.mh 2000/03/21 20:39:08 *************** *** 1,5 **** # Host: Intel 386 running NetBSD XDEPFILES= ser-tcp.o ! NATDEPFILES= fork-child.o infptrace.o inftarg.o corelow.o i386b-nat.o XM_FILE= xm-nbsd.h NAT_FILE= nm-nbsd.h --- 1,5 ---- # Host: Intel 386 running NetBSD XDEPFILES= ser-tcp.o ! NATDEPFILES= fork-child.o infptrace.o inftarg.o corelow.o i386nbsd-nat.o XM_FILE= xm-nbsd.h NAT_FILE= nm-nbsd.h /* Native-dependent code for NetBSD/i386, for GDB. Copyright 1988, 1989, 1991, 1992, 1994, 1996, 2000 Free Software Foundation, Inc. This file is part of GDB. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ #include "defs.h" #include #include #include #include #include "inferior.h" #include "gdbcore.h" /* for registers_fetched() */ #define RF(dst, src) \ memcpy(®isters[REGISTER_BYTE(dst)], &src, sizeof(src)) #define RS(src, dst) \ memcpy(&dst, ®isters[REGISTER_BYTE(src)], sizeof(dst)) struct env387 { unsigned short control; unsigned short r0; unsigned short status; unsigned short r1; unsigned short tag; unsigned short r2; unsigned long eip; unsigned short code_seg; unsigned short opcode; unsigned long operand; unsigned short operand_seg; unsigned short r3; unsigned char regs[8][10]; }; void fetch_inferior_registers (regno) int regno; { struct reg inferior_registers; struct env387 inferior_fpregisters; ptrace (PT_GETREGS, inferior_pid, (PTRACE_ARG3_TYPE) &inferior_registers, 0); ptrace (PT_GETFPREGS, inferior_pid, (PTRACE_ARG3_TYPE) &inferior_fpregisters, 0); RF ( 0, inferior_registers.r_eax); RF ( 1, inferior_registers.r_ecx); RF ( 2, inferior_registers.r_edx); RF ( 3, inferior_registers.r_ebx); RF ( 4, inferior_registers.r_esp); RF ( 5, inferior_registers.r_ebp); RF ( 6, inferior_registers.r_esi); RF ( 7, inferior_registers.r_edi); RF ( 8, inferior_registers.r_eip); RF ( 9, inferior_registers.r_eflags); RF (10, inferior_registers.r_cs); RF (11, inferior_registers.r_ss); RF (12, inferior_registers.r_ds); RF (13, inferior_registers.r_es); RF (14, inferior_registers.r_fs); RF (15, inferior_registers.r_gs); RF (FP0_REGNUM, inferior_fpregisters.regs[0]); RF (FP0_REGNUM + 1, inferior_fpregisters.regs[1]); RF (FP0_REGNUM + 2, inferior_fpregisters.regs[2]); RF (FP0_REGNUM + 3, inferior_fpregisters.regs[3]); RF (FP0_REGNUM + 4, inferior_fpregisters.regs[4]); RF (FP0_REGNUM + 5, inferior_fpregisters.regs[5]); RF (FP0_REGNUM + 6, inferior_fpregisters.regs[6]); RF (FP0_REGNUM + 7, inferior_fpregisters.regs[7]); RF (FCTRL_REGNUM, inferior_fpregisters.control); RF (FSTAT_REGNUM, inferior_fpregisters.status); RF (FTAG_REGNUM, inferior_fpregisters.tag); RF (FCS_REGNUM, inferior_fpregisters.code_seg); RF (FCOFF_REGNUM, inferior_fpregisters.eip); RF (FDS_REGNUM, inferior_fpregisters.operand_seg); RF (FDOFF_REGNUM, inferior_fpregisters.operand); RF (FOP_REGNUM, inferior_fpregisters.opcode); registers_fetched (); } void store_inferior_registers (regno) int regno; { struct reg inferior_registers; struct env387 inferior_fpregisters; RS ( 0, inferior_registers.r_eax); RS ( 1, inferior_registers.r_ecx); RS ( 2, inferior_registers.r_edx); RS ( 3, inferior_registers.r_ebx); RS ( 4, inferior_registers.r_esp); RS ( 5, inferior_registers.r_ebp); RS ( 6, inferior_registers.r_esi); RS ( 7, inferior_registers.r_edi); RS ( 8, inferior_registers.r_eip); RS ( 9, inferior_registers.r_eflags); RS (10, inferior_registers.r_cs); RS (11, inferior_registers.r_ss); RS (12, inferior_registers.r_ds); RS (13, inferior_registers.r_es); RS (14, inferior_registers.r_fs); RS (15, inferior_registers.r_gs); RS (FP0_REGNUM, inferior_fpregisters.regs[0]); RS (FP0_REGNUM + 1, inferior_fpregisters.regs[1]); RS (FP0_REGNUM + 2, inferior_fpregisters.regs[2]); RS (FP0_REGNUM + 3, inferior_fpregisters.regs[3]); RS (FP0_REGNUM + 4, inferior_fpregisters.regs[4]); RS (FP0_REGNUM + 5, inferior_fpregisters.regs[5]); RS (FP0_REGNUM + 6, inferior_fpregisters.regs[6]); RS (FP0_REGNUM + 7, inferior_fpregisters.regs[7]); RS (FCTRL_REGNUM, inferior_fpregisters.control); RS (FSTAT_REGNUM, inferior_fpregisters.status); RS (FTAG_REGNUM, inferior_fpregisters.tag); RS (FCS_REGNUM, inferior_fpregisters.code_seg); RS (FCOFF_REGNUM, inferior_fpregisters.eip); RS (FDS_REGNUM, inferior_fpregisters.operand_seg); RS (FDOFF_REGNUM, inferior_fpregisters.operand); RS (FOP_REGNUM, inferior_fpregisters.opcode); ptrace (PT_SETREGS, inferior_pid, (PTRACE_ARG3_TYPE) &inferior_registers, 0); ptrace (PT_SETFPREGS, inferior_pid, (PTRACE_ARG3_TYPE) &inferior_fpregisters, 0); } struct md_core { struct reg intreg; struct fpreg freg; }; void fetch_core_registers (core_reg_sect, core_reg_size, which, ignore) char *core_reg_sect; unsigned core_reg_size; int which; CORE_ADDR ignore; { struct md_core *core_reg = (struct md_core *) core_reg_sect; /* integer registers */ memcpy (®isters[REGISTER_BYTE (0)], &core_reg->intreg, sizeof (struct reg)); /* floating point registers */ /* XXX */ } -- J.T. Conklin RedBack Networks >From cgf@cygnus.com Sat Apr 01 00:00:00 2000 From: Chris Faylor To: Jim Blandy Cc: tromey@cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: Patch: hash tables for msymbols Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <20000303182733.A2742@cygnus.com> References: <87aeowo9jq.fsf@cygnus.com> X-SW-Source: 2000-q1/msg00487.html Content-length: 1135 On Fri, Mar 03, 2000 at 05:50:00PM -0500, Jim Blandy wrote: > >This looks good; please commit it to sourceware. Note that Keith Seitz found a minor problem with Tom's hashing code while investigating a problem reported by a Cygnus/Red Hat customer. He came up with the following patch which should be included if Tom's patch is finally applied to gdb sources. Tom, does this patch make sense? I believe that Fred Fish has also come up with a similar "speedup" patch. I don't know compares to Tom's, though. cgf *** gdb/minsyms.c.o Sun Feb 27 16:47:36 2000 --- gdb/minsyms.c Sun Feb 27 16:32:57 2000 *************** prim_record_minimal_symbol_and_info (nam *** 635,640 **** --- 635,646 ---- MSYMBOL_TYPE (msymbol) = ms_type; /* FIXME: This info, if it remains, needs its own field. */ MSYMBOL_INFO (msymbol) = info; /* FIXME! */ + + /* The hash pointers must be cleared! If they're not, + MSYMBOL_HASH_ADD will NOT add this msymbol to the hash table. */ + msymbol->hash_next = NULL; + msymbol->demangled_hash_next = NULL; + msym_bunch_index++; msym_count++; OBJSTAT (objfile, n_minsyms++);