From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fernando Nasser To: Jim Ingham Cc: Daniel Berlin , gdb-patches@sources.redhat.com Subject: Re: [patch] fix for infinite recursion in lookup_symbol Date: Mon, 15 Jan 2001 12:14:00 -0000 Message-id: <3A6359A8.EA9803FC@redhat.com> References: X-SW-Source: 2001-01/msg00129.html I just would like to add my 2cents to a few of Jim's remarks: Jim Ingham wrote: > > Daniel, > > >> I understand that there is some argument over whether the current > >> implementation of C++ symbol lookup is the right one, but while it is in > >> place, simple fixes to it need to get into the sources quickly. > > > > I'd happily check them in under an obvious bugfix rule, but I don't want > > to step on any toes. > > I had enough fun doing that trying to figure out what exact areas of code > > C++ maintainer covers, and I still couldn't tell you. > > If someone with definite maintainership over the symbol tables says I can > > check in the fixes, i'll do it. Otherwise, i won't. > > Sorry. > > I sympathize, but in this case the fix really is trivial... This one really > does fall under the obvious bugfix rule if any fix does... > People were questioning earlier today if such rule really exists. If it does not we are doomed. Specially with the current maintainers response time (including me -- we all have our hands full). We need a way to fix things quickly. If it needs a better fix it should be properly documented so people get to it as soon as they can. We cannot just leave things broken!!! If this is an attempt to force volunteers to make extra work and do code improvements and cleanups is not working. People are just giving up and leaving things broken. They are probably adding the fixes to their own copies and many other developers/users are suffering unnecessarily. > > > > Which explains why you keep mentioning users, when the bug only exists in > > CVS. > > This is a very bad idea to be doing. > > I really don't understand this. What else are we supposed to be basing our > sources on? There are two options here, apply patches from the Patches list > in advance of their acceptance, or just stick with "official" releases (i.e. > 5.0) > > There are lots of good patches, and lots of bad ones, in the patches mailing > list. It is better, I think, for us to let the "experts" in the Maintainers > group sort them out, and then use the results of this vetting process. That > IS what the whole Maintainer's (or Helpers??) structure is for. Seems like > subverting this process will just cause us more trouble. > > On the other hand, does anyone think an unmodified 5.0 is a good release to > base our efforts on? It has been around for a while now, and has its own > share of bugs that HAVE been fixed. In any case, you don't really WANT most > of your gdb users to stick with the 5.0 release, do you? That would mean > that the CVS changes are being tested by some set of Red Hat customers, and > that is about all. That would not be a very good idea. > GDB 5.0 is so old and so broken (at least Insight is) that it is useless to many people. If you look at the insight mailing list archives, people have been forced to download newer snapshots or even the CVS version because they just can't use the 5.0. If we had created a way to have a set of patches to 5.0 available, or even created some updated 5.0 releases with just bug fixes (no new feature -- bug fixes applied to the old 5.0 code base) this situation could be better. Even though, there would be things that the fixes would be to extensive to retrofit, and still people would have to resort to newer sources. And developers also waste many hours because of known bugs with minor fixes that just werent comitted. No matter how I look at it I can't find a good reason to leave bugs laying around when a fix is known. -- Fernando Nasser Red Hat Canada Ltd. E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9 >From kevinb@cygnus.com Mon Jan 15 12:34:00 2001 From: Kevin Buettner To: Fernando Nasser Cc: gdb-patches@sources.redhat.com Subject: Re: RFA: [infrun.c] Fix to "nexti". Date: Mon, 15 Jan 2001 12:34:00 -0000 Message-id: <1010115203401.ZM6558@ocotillo.lan> References: <3A54D5D2.CCA3E45E@redhat.com> <3A59DE42.5295C9A5@cygnus.com> <3A6318BF.A9A43A10@redhat.com> <20010115113635.B26739@redhat.com> <1010115175046.ZM6315@ocotillo.lan> <3A63418D.513E833@redhat.com> X-SW-Source: 2001-01/msg00130.html Content-length: 2437 On Jan 15, 1:29pm, Fernando Nasser wrote: > Kevin Buettner wrote: > > > > On Jan 15, 11:36am, Christopher Faylor wrote: > > > > > On Mon, Jan 15, 2001 at 10:35:27AM -0500, Fernando Nasser wrote: > > > >If there is a maintainer for this code please speak up. > > > > > > > >Otherwise I will check this in under the "obvious fix" rule. > > > > > > Do we really have an "obvious fix" rule? It seems that there is > > > some confusion on this issue. > > > > We do not have an "obvious fix" rule. See > > > > http://sources.redhat.com/ml/gdb-patches/2000-04/msg00468.html > > > > If you go throughout the list you'll find that it has been mentioned and > invoked several times in other messages. It is not well defined though, > and it does not seem to be written anywhere either. Would you mind pointing a few of these out? I've searched for "obvious" in the gdb-patches archive, but it generates a lot of hits. (I'm curious about whether it's "blanket write privs" maintainers who are invoking this rule.) > As it is not written what to do when the maintainers do not respond and > something is broken. Do we keep downloading rotten code? These bugs > are very costly in that people waste hours of work because of them. I don't know what the right answer is. With regard to the infrun.c patch, however, I did take a look at it and it wasn't clear to me that it was "obviously" right. I'm not saying it's wrong either, but that code is complicated and requires some study. > The message above mentions a problem with regards to small fixes in > codes outside one's maintainership that go wrong. Sometimes > the original problem is fixed but some other is created. > That is why we use CVS. The change can be reversed and the maintainer > (when he/she shows up) has a complete record of what has been changed > and > why (in addition to the list archives). > > I don't know what is the better/right solution to the problem, but we do > have a problem now with regarding to bug fixes, specially small fix to > harmful ones. We do need a fast track to them and even consider > temporary > fixes (properly marked with FIXME and entries in the TODO file). If those of us working on gdb could have some of their time freed up to spend on our maintainership duties, that will clearly be a step in the right direction. But I agree that we ought to have a process in place to deal with the situations you describe. >From geoffk@geoffk.org Mon Jan 15 15:29:00 2001 From: Geoff Keating To: gdb-patches@sources.redhat.com Subject: patch for ppc sim to fix open() Date: Mon, 15 Jan 2001 15:29:00 -0000 Message-id: <200101152329.PAA00837@geoffk.org> X-SW-Source: 2001-01/msg00131.html Content-length: 1960 This makes the sim's emulation of the open() syscall match NetBSD, even on hosts where the constants are different. I wanted this so that Perennial tests could create temporary files. (It's also dangerous to call open() with random flag values.) -- - Geoffrey Keating ===File ~/patches/cygnus/sim-ppcopen.patch================== 2000-12-29 Geoffrey Keating * emul_netbsd.c (do_open): Translate the flag parameter to the open syscall to the numbers supported by the host. Index: emul_netbsd.c =================================================================== RCS file: /cvs/cvsfiles/devo/sim/ppc/emul_netbsd.c,v retrieving revision 1.30 diff -u -p -r1.30 emul_netbsd.c --- emul_netbsd.c 2000/03/02 09:22:28 1.30 +++ emul_netbsd.c 2001/01/09 22:51:06 @@ -386,6 +386,7 @@ do_open(os_emul_data *emul, char *path = emul_read_string(path_buf, path_addr, PATH_MAX, processor, cia); int flags = (int)cpu_registers(processor)->gpr[arg0+1]; int mode = (int)cpu_registers(processor)->gpr[arg0+2]; + int hostflags; int status; if (WITH_TRACE && ppc_trace[trace_os_emul]) @@ -393,8 +394,25 @@ do_open(os_emul_data *emul, SYS(open); + /* Do some translation on 'flags' to match it to the host's version. */ + /* These flag values were taken from the NetBSD 1.4 header files. */ + if ((flags & 3) == 0) + hostflags = O_RDONLY; + else if ((flags & 3) == 1) + hostflags = O_WRONLY; + else + hostflags = O_RDWR; + if (flags & 0x00000008) + hostflags |= O_APPEND; + if (flags & 0x00000200) + hostflags |= O_CREAT; + if (flags & 0x00000400) + hostflags |= O_TRUNC; + if (flags & 0x00000800) + hostflags |= O_EXCL; + /* Can't combine these statements, cuz open sets errno. */ - status = open(path, flags, mode); + status = open(path, hostflags, mode); emul_write_status(processor, status, errno); } ============================================================ >From jtc@redback.com Mon Jan 15 18:08:00 2001 From: jtc@redback.com (J.T. Conklin) To: gdb-patches@sourceware.cygnus.com Subject: patch to split embedded and linux sh targets Date: Mon, 15 Jan 2001 18:08:00 -0000 Message-id: <5mzogss0zd.fsf@jtc.redback.com> X-SW-Source: 2001-01/msg00132.html Content-length: 2976 I submit the enclosed patch for a approval. The current sh target, which was once a embedded only target has been made gnu/linux-specific by the inclusion of shared library support. This patch creates a embedded target (sh-*-coff*, sh-*-elf*) by moving the linux bits to its own configuration (sh-*-linux*). I haven't changed the linux config other than by renaming sh.mt to linux.mt, although I believe that support for the SH3 ROM monitor, the e7000 ICE, and perhaps the SH simulator can be removed. --jtc 2001-01-15 J.T. Conklin * configure/sh/embed.mt: New file. * configure/sh/linux.mt: New file. * configure/sh/sh.mt: Removed. * configure.tgt (sh-*-coff*, sh-*-elf*, sh-*-linux): New targets. (sh-*-*): Removed. Index: configure.tgt =================================================================== RCS file: /cvs/src/src/gdb/configure.tgt,v retrieving revision 1.16 diff -c -r1.16 configure.tgt *** configure.tgt 2000/12/14 20:15:45 1.16 --- configure.tgt 2001/01/16 02:01:57 *************** *** 263,269 **** rs6000-*-*) gdb_target=rs6000 ;; sh*-*-pe) gdb_target=wince ;; ! sh-*-*) gdb_target=sh ;; sparc-*-aout*) gdb_target=sparc-em ;; sparc-*-coff*) gdb_target=sparc-em ;; --- 263,271 ---- rs6000-*-*) gdb_target=rs6000 ;; sh*-*-pe) gdb_target=wince ;; ! sh-*-coff*) gdb_target=embed ;; ! sh-*-elf*) gdb_target=embed ;; ! sh-*-linux*) gdb_target=linux ;; sparc-*-aout*) gdb_target=sparc-em ;; sparc-*-coff*) gdb_target=sparc-em ;; Index: config/sh/embed.mt =================================================================== RCS file: embed.mt diff -N embed.mt *** /dev/null Tue May 5 13:32:27 1998 --- embed.mt Mon Jan 15 18:01:57 2001 *************** *** 0 **** --- 1,6 ---- + # Target: Embedded Hitachi Super-H with ICE and simulator + TDEPFILES= sh-tdep.o monitor.o sh3-rom.o remote-e7000.o ser-e7kpc.o dsrec.o + TM_FILE= tm-sh.h + + SIM_OBS = remote-sim.o + SIM = ../sim/sh/libsim.a Index: config/sh/linux.mt =================================================================== RCS file: linux.mt diff -N linux.mt *** /dev/null Tue May 5 13:32:27 1998 --- linux.mt Mon Jan 15 18:01:57 2001 *************** *** 0 **** --- 1,6 ---- + # Target: Hitachi Super-H running GNU/Linux + TDEPFILES= sh-tdep.o monitor.o sh3-rom.o remote-e7000.o ser-e7kpc.o dsrec.o solib.o solib-svr4.o + TM_FILE= tm-linux.h + + SIM_OBS = remote-sim.o + SIM = ../sim/sh/libsim.a Index: config/sh/sh.mt =================================================================== RCS file: sh.mt diff -N sh.mt *** /sourceware/cvs-tmp/cvsiq6IWP Mon Jan 15 18:01:58 2001 --- /dev/null Tue May 5 13:32:27 1998 *************** *** 1,6 **** - # Target: Hitachi Super-H with ICE and simulator - TDEPFILES= sh-tdep.o monitor.o sh3-rom.o remote-e7000.o ser-e7kpc.o dsrec.o solib.o solib-svr4.o - TM_FILE= tm-linux.h - - SIM_OBS = remote-sim.o - SIM = ../sim/sh/libsim.a --- 0 ---- -- J.T. Conklin RedBack Networks >From ac131313@cygnus.com Mon Jan 15 19:39:00 2001 From: Andrew Cagney To: Nick Duffek Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] New register definition interface Date: Mon, 15 Jan 2001 19:39:00 -0000 Message-id: <3A63C202.F418E4ED@cygnus.com> References: <3A62408E.A745B2D6@cygnus.com> <200101151859.f0FIxqG05555@rtl.cygnus.com> X-SW-Source: 2001-01/msg00133.html Content-length: 2999 Nick Duffek wrote: > The same issue applies to cli-regs.c: cliregs_init() attaches memory to > each architecture even if the architecture hasn't set cliregs_info() as > its do_registers_info callback. > > Some possible solutions: > > 1. Each competing module implementation introduces a gdbarch variable > USE_ that architectures must set to 1 if > they're using that implementation. For example: I don't think it will scale. It is a bit like those GDB_ARCHITECTURE_IS_D10V et.al. we'd all like to get rid of. The tests should be for functionality not implementation. However, a hack of yes/no ``register_module_installed_p'' flag might be useful so that the default case (regcache) knows to not install its self. > 2. Each module introduces a gdbarch variable MODULE_ that > architectures must set to an implementation-unique value. Definitly not this one. Look at the spaghetti found in sim/common (yes I'm in part to blame for that one :-) > 3. Introduce a gdbarch interface to query function pointers. Competing > module implementations can use these to check whether they're being > used by the current architecture. For example: > > if (GET_DO_REGISTERS_INFO () != cliregs_info) > return; I don't think it should be necessary. Module implementations shouldn't be competing - once a module, for a given architecture, is selected the competing modules should never be seen again. Did I mention sim/common :-) The only exception would be where gdbarch asks the question ``has any module been installed?'' If no - install the default. > /* allocate memory */ > > To avoid the footprint of a GET_*() function for every gdbarch.sh > entry, a per-entry flag could be added that controls whether that > function is needed. 4. Add a function like: set_gdbarch_data (struct gdbarch *gdbarch, struct gdbarch_data *handle, void *value); so that instead of waiting for gdbarch to call your module, your module, as part of its set-up, calls gdbarch vis: gdbarch calls ..._gdbarch_init() -> calls your_module's_init_or_setup_or_something() -> calls set_gdbarch_data (gdbarch, your_modules_handle, your_modules_data); -> calls set_various_other_methods (...); (mumble something about fine print, memory leaks and deleting architectures :-) I wouldn't be too worried if it for the short term (for GDB that is about a year :-) build_regcache() still allocated a buffer - that is an implementation issue (like using bubble sort :-). I'm worried about interfaces not implementations :-). Just document the problem in the code and TODO files. Alternativly, like you were outlining, some sort of check to see if a competing module hasn't already been installed. Long long term, the register stuff could be combined into a group so that it are installed as a block - instead of the N separate register methods. Again, that is a separate problem. Andrew >From ac131313@cygnus.com Mon Jan 15 19:44:00 2001 From: Andrew Cagney To: Nick Duffek Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] New register definition interface Date: Mon, 15 Jan 2001 19:44:00 -0000 Message-id: <3A63C32F.5031F1FB@cygnus.com> References: <3A62408E.A745B2D6@cygnus.com> <200101151859.f0FIxqG05555@rtl.cygnus.com> X-SW-Source: 2001-01/msg00134.html Content-length: 653 Nick Duffek wrote: > Speaking of gdbarch.sh changes, what do you think about the idea of > translating gdbarch.sh into C and automatically generating gdbarch.[ch] as > transient compile-time entities? Running gdbarch.sh takes about 25 > seconds on my 650MHz Pentium, and I often forget to run it after applying > or reverting patches that change it. I wish :-) The plan is to eventually have things autogenerated when GDB is configured with --enable-maintainer-mode. Unfortunatly it can't be made the default as you can bet your bottom dollar that gdbarch.sh will break on some critical platform shell :-( I'll add this to the TODO file. Andrew >From bje@redhat.com Mon Jan 15 22:33:00 2001 From: Ben Elliston To: gdb-patches@sources.redhat.com Cc: bje@redhat.com Subject: [testsuite] Contribution to testsuite/config Date: Mon, 15 Jan 2001 22:33:00 -0000 Message-id: <200101160633.f0G6X4N19524@scooby.cygnus.com> X-SW-Source: 2001-01/msg00135.html Content-length: 4961 Attached is a copy of `sid.exp' -- a config file for DejaGNU to permit GDB testing on simulators in the SID framework. Okay to commit? 2001-01-16 Ben Elliston * config/sid.exp: New file. # Test Framework Driver for GDB driving an external simulator # Copyright 1999 Free Software Foundation, Inc. ? # # 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. load_lib gdb.exp proc sid_start {} { global sid_spawn_id global verbose set port [lindex [split [target_info netport] ":"] 1] # Set a default endianness case [target_info multilib_flags] in { { *big-endian* *-EB* *-meb* } { set sidendian "-EB" } { *little-endian* *-EL* *-mel* } { set sidendian "-EL" } default { if {[target_info exists sim,defaultendian]} then { set sidendian [target_info sim,defaultendian] } else { warning "Unknown target endianness - assuming -EB" set sidendian "-EB" } } } # set verbosity conditionally if {$verbose > 0} then { set sidverbose "--verbose" } else { set sidverbose "" } # test to see whether to use use sid in build or install tree set use_build_tree [file exists ../../sid] if {$use_build_tree} then { set pre_spawn { global env set env(SID_LIBRARY_PATH) [join [glob "../../sid/component/*"] ":"] set env(SID) "../../sid/main/dynamic/sid" set env(MKSID) "../../sid/main/static/mksid" if {! [file exists $env(SID)]} then { error "Cannot find sid in build tree" } } set spawncmd "../../sid/bsp/[target_info sim] $sidverbose $sidendian --persistent --gdb=$port [target_info sim,options]" set post_spawn { global env unset env(SID_LIBRARY_PATH) unset env(MKSID) unset env(SID) } } else { set pre_spawn {} set spawncmd "[target_info sim] $sidverbose $sidendian --persistent --gdb=$port [target_info sim,options]" set post_spawn {} } eval $pre_spawn if {[catch "spawn $spawncmd" msg]} { perror $msg exit 1 } eval $post_spawn expect_background { -re \[^\n\]*\n { regsub "\n" $expect_out(buffer) {} msg verbose "SID: $msg" 2 } } # There should be no need to sleep to give SID time to start; # GDB would wait for a fair while for the stub to respond. sleep 4 set sid_spawn_id $spawn_id } # # Handle GDB talking to SID # proc gdb_start {} { sid_start return [default_gdb_start] } proc sid_exit {} { global sid_spawn_id if {[info exists sid_spawn_id]} { catch {exec kill [exp_pid -i $sid_spawn_id]} catch {wait -i $sid_spawn_id} unset sid_spawn_id sleep 4 } } proc gdb_exit {} { set result [default_gdb_exit] sid_exit return $result } # # gdb_target_sid # Set gdb to target the simulator # proc send_target_sid { } { # wait a little while, giving sid time to shut down & restart its # gdb socket sleep 4 send_gdb "target [target_info gdb_protocol] [target_info netport]\n" } proc gdb_target_sid { } { global gdb_prompt global exit_status send_target_sid global timeout set prev_timeout $timeout set timeout 60 verbose "Timeout is now $timeout seconds" 2 gdb_expect { -re "Remote debugging using.*$gdb_prompt" { verbose "Set target to sid" } timeout { perror "Couldn't set target for remote simulator." cleanup exit $exit_status } } set timeout $prev_timeout verbose "Timeout is now $timeout seconds" 2 } # # gdb_load -- load a file into the debugger. # return a -1 if anything goes wrong. # proc gdb_load { arg } { global verbose global loadpath global loadfile global GDB global gdb_prompt gdb_unload if [gdb_file_cmd $arg] then { return -1 } gdb_target_sid send_gdb "load\n" global timeout set prev_timeout $timeout set timeout 2400 verbose "Timeout is now $timeout seconds" 2 gdb_expect { -re ".*$gdb_prompt $" { if $verbose>1 then { send_user "Loaded $arg into $GDB\n" } set timeout 30 verbose "Timeout is now $timeout seconds" 2 return 1 } -re "$gdb_prompt $" { if $verbose>1 then { perror "GDB couldn't load." } } timeout { if $verbose>1 then { perror "Timed out trying to load $arg." } } } set timeout $prev_timeout } >From fnasser@cygnus.com Tue Jan 16 08:56:00 2001 From: Fernando Nasser To: Ben Elliston Cc: gdb-patches@sources.redhat.com Subject: Re: [testsuite] Contribution to testsuite/config Date: Tue, 16 Jan 2001 08:56:00 -0000 Message-id: <3A647D4B.4B343299@cygnus.com> References: <200101160633.f0G6X4N19524@scooby.cygnus.com> X-SW-Source: 2001-01/msg00136.html Content-length: 6022 Ben Elliston wrote: > > Attached is a copy of `sid.exp' -- a config file for DejaGNU to permit > GDB testing on simulators in the SID framework. Okay to commit? > Sure thanks. Fernando > 2001-01-16 Ben Elliston > > * config/sid.exp: New file. > > # Test Framework Driver for GDB driving an external simulator > # Copyright 1999 Free Software Foundation, Inc. ? > # > # 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. > > load_lib gdb.exp > > proc sid_start {} { > global sid_spawn_id > global verbose > > set port [lindex [split [target_info netport] ":"] 1] > > # Set a default endianness > case [target_info multilib_flags] in { > { *big-endian* *-EB* *-meb* } { set sidendian "-EB" } > { *little-endian* *-EL* *-mel* } { set sidendian "-EL" } > default { > if {[target_info exists sim,defaultendian]} then { > set sidendian [target_info sim,defaultendian] > } else { > warning "Unknown target endianness - assuming -EB" > set sidendian "-EB" > } > } > } > # set verbosity conditionally > if {$verbose > 0} then { set sidverbose "--verbose" } else { set sidverbose "" } > > # test to see whether to use use sid in build or install tree > set use_build_tree [file exists ../../sid] > > if {$use_build_tree} then { > set pre_spawn { > global env > set env(SID_LIBRARY_PATH) [join [glob "../../sid/component/*"] ":"] > set env(SID) "../../sid/main/dynamic/sid" > set env(MKSID) "../../sid/main/static/mksid" > if {! [file exists $env(SID)]} then { error "Cannot find sid in build tree" } > } > set spawncmd "../../sid/bsp/[target_info sim] $sidverbose $sidendian --persistent --gdb=$port [target_info sim,options]" > set post_spawn { > global env > unset env(SID_LIBRARY_PATH) > unset env(MKSID) > unset env(SID) > } > } else { > set pre_spawn {} > set spawncmd "[target_info sim] $sidverbose $sidendian --persistent --gdb=$port [target_info sim,options]" > set post_spawn {} > } > > eval $pre_spawn > if {[catch "spawn $spawncmd" msg]} { > perror $msg > exit 1 > } > eval $post_spawn > > expect_background { > -re \[^\n\]*\n { > regsub "\n" $expect_out(buffer) {} msg > verbose "SID: $msg" 2 > } > } > > # There should be no need to sleep to give SID time to start; > # GDB would wait for a fair while for the stub to respond. > sleep 4 > > set sid_spawn_id $spawn_id > } > > # > # Handle GDB talking to SID > # > > proc gdb_start {} { > sid_start > return [default_gdb_start] > } > > proc sid_exit {} { > global sid_spawn_id > if {[info exists sid_spawn_id]} { > catch {exec kill [exp_pid -i $sid_spawn_id]} > catch {wait -i $sid_spawn_id} > unset sid_spawn_id > sleep 4 > } > } > > proc gdb_exit {} { > set result [default_gdb_exit] > sid_exit > return $result > } > > # > # gdb_target_sid > # Set gdb to target the simulator > # > proc send_target_sid { } { > # wait a little while, giving sid time to shut down & restart its > # gdb socket > sleep 4 > send_gdb "target [target_info gdb_protocol] [target_info netport]\n" > } > > proc gdb_target_sid { } { > global gdb_prompt > global exit_status > > send_target_sid > > global timeout > set prev_timeout $timeout > set timeout 60 > verbose "Timeout is now $timeout seconds" 2 > gdb_expect { > -re "Remote debugging using.*$gdb_prompt" { > verbose "Set target to sid" > } > timeout { > perror "Couldn't set target for remote simulator." > cleanup > exit $exit_status > } > } > set timeout $prev_timeout > verbose "Timeout is now $timeout seconds" 2 > } > > # > # gdb_load -- load a file into the debugger. > # return a -1 if anything goes wrong. > # > proc gdb_load { arg } { > global verbose > global loadpath > global loadfile > global GDB > global gdb_prompt > > gdb_unload > if [gdb_file_cmd $arg] then { return -1 } > gdb_target_sid > > send_gdb "load\n" > global timeout > set prev_timeout $timeout > set timeout 2400 > verbose "Timeout is now $timeout seconds" 2 > gdb_expect { > -re ".*$gdb_prompt $" { > if $verbose>1 then { > send_user "Loaded $arg into $GDB\n" > } > set timeout 30 > verbose "Timeout is now $timeout seconds" 2 > return 1 > } > -re "$gdb_prompt $" { > if $verbose>1 then { > perror "GDB couldn't load." > } > } > timeout { > if $verbose>1 then { > perror "Timed out trying to load $arg." > } > } > } > set timeout $prev_timeout > } -- Fernando Nasser Red Hat - Toronto E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9 >From fnasser@cygnus.com Tue Jan 16 09:27:00 2001 From: Fernando Nasser To: Michael Snyder Cc: gdb-patches@sources.redhat.com Subject: Re: [Fwd: RFA: [infrun.c] Fix to "nexti".] Date: Tue, 16 Jan 2001 09:27:00 -0000 Message-id: <3A648467.8B949E89@cygnus.com> References: <3A634581.9C1C76CD@redhat.com> X-SW-Source: 2001-01/msg00137.html Content-length: 2278 Michael Snyder wrote: > > Christopher Faylor wrote: > > > > On Mon, Jan 15, 2001 at 10:35:27AM -0500, Fernando Nasser wrote: > > >If there is a maintainer for this code please speak up. > > > > > >Otherwise I will check this in under the "obvious fix" rule. > > > > Do we really have an "obvious fix" rule? It seems that there is > > some confusion on this issue. > > We do (I think), but when you're discussing infrun.c, I'm not > sure that any change can be regarded as "obviously correct". > At least not in the wait_for_inferior/handle_event area. > Well, someone must be able to evaluate it and make a decision. This thing has no specific maintainer (I could not find in the MAINTAINERS file) and people keep avoiding it. But it is broken and has to be fixed. What are we going to to about it? Or will we add in the Users manual that a "nexti" command should not be used inside a function prologue or it will work as a "continue"? > By eyeball, this change looks correct to me, or at least > "not obviously incorrect". I would like to see it tested, > and perhaps the best way to do that is to apply it and then > notice if there's a sudden uptick in testsuite failures. > Well, of course I run the testsuite on it on a couple of targets and with a couple of versions of gcc. This means little with this code as it is used by all targets but what else can I do? When the code that was originally there was removed years ago and replaced with a very simplified test, all the knowledge that was accumulated over the years about different situations that can arise was lost. All that we can do know is to start accumulating that knowledge again by adding the appropriate tests for the cases where it fails. But if the bug fixes are just ignored and remain as a lost message in the list archives we will never evolve from where we are now. We could have a page with known bugs and patches that fix them, with some mechanism for feedback. But at the moment, all we can do is to install the fix and see if there is some hidden condition that was not accounted for and either revert it or refine it further. -- Fernando Nasser Red Hat - Toronto E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9 >From msnyder@cygnus.com Tue Jan 16 09:36:00 2001 From: Michael Snyder To: gdb-patches@sources.redhat.com Subject: [PATCH] Fix typo in comment. Date: Tue, 16 Jan 2001 09:36:00 -0000 Message-id: <200101161736.JAA18782@cleaver.cygnus.com> X-SW-Source: 2001-01/msg00138.html Content-length: 1324 2001-01-16 Michael Snyder * source.c (openp): Fix typo in comment. Index: source.c =================================================================== RCS file: /cvs/src/src/gdb/source.c,v retrieving revision 1.6 diff -c -3 -p -r1.6 source.c *** source.c 2000/12/15 01:01:49 1.6 --- source.c 2001/01/16 17:34:51 *************** source_info (char *ignore, int from_tty) *** 500,506 **** so that "exec-file ./foo" or "symbol-file ./foo" insures that you get that particular version of foo or an error message). ! If FILENAMED_OPENED is non-null, set it to a newly allocated string naming the actual file opened (this string will always start with a "/". We have to take special pains to avoid doubling the "/" between the directory and the file, sigh! Emacs gets confuzzed by this when we print the --- 500,506 ---- so that "exec-file ./foo" or "symbol-file ./foo" insures that you get that particular version of foo or an error message). ! If FILENAME_OPENED is non-null, set it to a newly allocated string naming the actual file opened (this string will always start with a "/". We have to take special pains to avoid doubling the "/" between the directory and the file, sigh! Emacs gets confuzzed by this when we print the >From msnyder@cygnus.com Tue Jan 16 09:41:00 2001 From: Michael Snyder To: gdb-patches@sources.redhat.com Subject: [PATCH]: minor fix to procfs_stopped_by_watchpoint Date: Tue, 16 Jan 2001 09:41:00 -0000 Message-id: <200101161741.JAA18804@cleaver.cygnus.com> X-SW-Source: 2001-01/msg00139.html Content-length: 1054 2001-01-16 Michael Snyder * procfs.c (procfs_stopped_by_watchpoint): Don't die if process goes away -- just return false (ie. not stopped by watchpoint). Index: procfs.c =================================================================== RCS file: /cvs/src/src/gdb/procfs.c,v retrieving revision 1.21 diff -c -3 -p -r1.21 procfs.c *** procfs.c 2000/12/15 01:01:48 1.21 --- procfs.c 2001/01/16 17:39:47 *************** procfs_stopped_by_watchpoint (int pid) *** 4793,4800 **** { procinfo *pi; ! pi = find_procinfo_or_die (pid == -1 ? ! PIDGET (inferior_pid) : PIDGET (pid), 0); if (proc_flags (pi) & (PR_STOPPED | PR_ISTOP)) { if (proc_why (pi) == PR_FAULTED) --- 4793,4804 ---- { procinfo *pi; ! pi = find_procinfo (pid == -1 ? ! PIDGET (inferior_pid) : PIDGET (pid), 0); ! ! if (!pi) /* If no process, then not stopped by watchpoint! */ ! return 0; ! if (proc_flags (pi) & (PR_STOPPED | PR_ISTOP)) { if (proc_why (pi) == PR_FAULTED) >From nsd@redhat.com Tue Jan 16 12:17:00 2001 From: Nick Duffek To: ac131313@cygnus.com Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] New register definition interface Date: Tue, 16 Jan 2001 12:17:00 -0000 Message-id: <200101162018.PAA27643@nog.bosbc.com> References: <3A63C202.F418E4ED@cygnus.com> X-SW-Source: 2001-01/msg00140.html Content-length: 1564 On 16-Jan-2001, Andrew Cagney wrote: >4. Add a function like: > > set_gdbarch_data (struct gdbarch *gdbarch, > struct gdbarch_data *handle, > void *value); [...] > gdbarch calls ..._gdbarch_init() > -> calls your_module's_init_or_setup_or_something() > -> calls set_gdbarch_data (gdbarch, your_modules_handle, >your_modules_data); > -> calls set_various_other_methods (...); That looks good to me. It's very similar to what regs.c does, except that it calls set_gdbarch_register_list() instead of set_gdbarch_data(). Specifically: 1. _gdbarch_init() in -tdep.c calls regs_init_finish(). 2. regs_init_finish() calls set_gdbarch_register_list(). 3. regs_init_finish() also calls set_gdbarch_num_regs() and various other set_gdbarch_*() functions. For regs.c, I really need to do the above or something similar, because the information collected between regs_init_start() and regs_init_finish() must be attached to . For cli-regs.c, I can use register_gdbarch_data() if I'm willing to waste memory. I can deal with the memory waste by: 1. ignoring it; 2. using regs.c's approach with e.g. CLIREGS_INTERNAL instead of REGISTER_LIST; 3. implementing set_gdbarch_data(). I'd prefer 2 or 3. Do you have a preference? >However, a hack of yes/no ``register_module_installed_p'' flag might be >useful so that the default case (regcache) knows to not install its >self. Since we're talking hacks, I think I might as well use REGISTER_LIST rather than adding a new REGISTER_MODULE_INSTALLED_P method. Nick >From ac131313@cygnus.com Tue Jan 16 14:33:00 2001 From: Andrew Cagney To: Nick Duffek Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] New register definition interface Date: Tue, 16 Jan 2001 14:33:00 -0000 Message-id: <3A64CBAE.D480ADB7@cygnus.com> References: <3A63C202.F418E4ED@cygnus.com> <200101162018.PAA27643@nog.bosbc.com> X-SW-Source: 2001-01/msg00141.html Content-length: 1164 Nick Duffek wrote: > > On 16-Jan-2001, Andrew Cagney wrote: > > >4. Add a function like: > > > > set_gdbarch_data (struct gdbarch *gdbarch, > > struct gdbarch_data *handle, > > void *value); > [...] > > gdbarch calls ..._gdbarch_init() > > -> calls your_module's_init_or_setup_or_something() > > -> calls set_gdbarch_data (gdbarch, your_modules_handle, > >your_modules_data); > > -> calls set_various_other_methods (...); > > That looks good to me. It's very similar to what regs.c does, except that > it calls set_gdbarch_register_list() instead of set_gdbarch_data(). The difference is that the data is kept private to the regs.c file (those interfaces again). It isn't possible for external code to go grubbing around in internals when you're not looking. > Since we're talking hacks, I think I might as well use REGISTER_LIST > rather than adding a new REGISTER_MODULE_INSTALLED_P method. The nice thing about REGISTER_MODULE_INSTALLED_P() is that it is so informative that the caller can conclude nothing about the actual module. This is a good thing :-) Andrew >From jtc@redback.com Tue Jan 16 14:59:00 2001 From: jtc@redback.com (J.T. Conklin) To: Fernando Nasser Cc: matthew green , gdb-patches@sources.redhat.com Subject: Re: patch for compiles that don't define "unix" Date: Tue, 16 Jan 2001 14:59:00 -0000 Message-id: <5mvgrf6r3a.fsf@jtc.redback.com> References: <22097.979473536@cygnus.com> <3A61CF62.34A9FFE2@redhat.com> X-SW-Source: 2001-01/msg00142.html Content-length: 1814 >>>>> "Fernando" == Fernando Nasser writes: Fernando> This is not the proper fix though. The rdi-share Fernando> subdirectory is supposed to contain code shared with ARM, so Fernando> we shouldn't make local modifications in there (unless Fernando> absolutely necessary). Doesn't "sharing" imply something more than just importing third party code? There should be a mechanism where we can at least advocate that a change be made to shared source. I note that there are a lot of __CYGWIN32__ conditionals. How did they get into rdi-share? Unfortunately there is no documentation within rdi- share that says how to obtain the master copy so I can compare, but it ultimately doesn't matter. Either there is a mechanism to get these changes incorporated, or the rule about making local changes is flexible. Fernando> In this case we are better off with a more general fix that Fernando> will solve all possible occurrences of the lack of "unix" Fernando> problem. While mrg came up with an alternate patch, I'm not convinced it's better than his original. The original patch made defined __unix if either "unix" or "__unix__" is defined. IMO, this makes a lot more sense than the alternate solution where __unix is defined if unix is defined in host.h, but __unix is defined if __unix__ is defined via autoconf & makefiles. But if you take a look at how __unix is used, you'll see that it is used to determine whether the host is a "fairly recent" UN*X-ish host. It's used to determine whether to use sigaction() or signal(), whether the host has gettimeofday(), etc. IMO, these are should be replaced by specific feature tests. I suspect that a lot of older UN*X systems that define unix will not build rdi-share sources as is. --jtc -- J.T. Conklin RedBack Networks >From msnyder@redhat.com Tue Jan 16 15:02:00 2001 From: Michael Snyder To: jtc@redback.com Cc: gdb-patches@sourceware.cygnus.com Subject: Re: patch to split embedded and linux sh targets Date: Tue, 16 Jan 2001 15:02:00 -0000 Message-id: <3A64D310.6A39F1D7@redhat.com> References: <5mzogss0zd.fsf@jtc.redback.com> X-SW-Source: 2001-01/msg00143.html Content-length: 3504 JT, What exactly is broken? What are you fixing? As far as I know, "sh-elf" builds, and so does "sh-linux-elf". "J.T. Conklin" wrote: > > I submit the enclosed patch for a approval. The current sh target, > which was once a embedded only target has been made gnu/linux-specific > by the inclusion of shared library support. > > This patch creates a embedded target (sh-*-coff*, sh-*-elf*) by moving > the linux bits to its own configuration (sh-*-linux*). I haven't > changed the linux config other than by renaming sh.mt to linux.mt, > although I believe that support for the SH3 ROM monitor, the e7000 > ICE, and perhaps the SH simulator can be removed. > > --jtc > > 2001-01-15 J.T. Conklin > > * configure/sh/embed.mt: New file. > * configure/sh/linux.mt: New file. > * configure/sh/sh.mt: Removed. > * configure.tgt (sh-*-coff*, sh-*-elf*, sh-*-linux): New targets. > (sh-*-*): Removed. > > Index: configure.tgt > =================================================================== > RCS file: /cvs/src/src/gdb/configure.tgt,v > retrieving revision 1.16 > diff -c -r1.16 configure.tgt > *** configure.tgt 2000/12/14 20:15:45 1.16 > --- configure.tgt 2001/01/16 02:01:57 > *************** > *** 263,269 **** > rs6000-*-*) gdb_target=rs6000 ;; > > sh*-*-pe) gdb_target=wince ;; > ! sh-*-*) gdb_target=sh ;; > > sparc-*-aout*) gdb_target=sparc-em ;; > sparc-*-coff*) gdb_target=sparc-em ;; > --- 263,271 ---- > rs6000-*-*) gdb_target=rs6000 ;; > > sh*-*-pe) gdb_target=wince ;; > ! sh-*-coff*) gdb_target=embed ;; > ! sh-*-elf*) gdb_target=embed ;; > ! sh-*-linux*) gdb_target=linux ;; > > sparc-*-aout*) gdb_target=sparc-em ;; > sparc-*-coff*) gdb_target=sparc-em ;; > Index: config/sh/embed.mt > =================================================================== > RCS file: embed.mt > diff -N embed.mt > *** /dev/null Tue May 5 13:32:27 1998 > --- embed.mt Mon Jan 15 18:01:57 2001 > *************** > *** 0 **** > --- 1,6 ---- > + # Target: Embedded Hitachi Super-H with ICE and simulator > + TDEPFILES= sh-tdep.o monitor.o sh3-rom.o remote-e7000.o ser-e7kpc.o dsrec.o > + TM_FILE= tm-sh.h > + > + SIM_OBS = remote-sim.o > + SIM = ../sim/sh/libsim.a > Index: config/sh/linux.mt > =================================================================== > RCS file: linux.mt > diff -N linux.mt > *** /dev/null Tue May 5 13:32:27 1998 > --- linux.mt Mon Jan 15 18:01:57 2001 > *************** > *** 0 **** > --- 1,6 ---- > + # Target: Hitachi Super-H running GNU/Linux > + TDEPFILES= sh-tdep.o monitor.o sh3-rom.o remote-e7000.o ser-e7kpc.o dsrec.o solib.o solib-svr4.o > + TM_FILE= tm-linux.h > + > + SIM_OBS = remote-sim.o > + SIM = ../sim/sh/libsim.a > Index: config/sh/sh.mt > =================================================================== > RCS file: sh.mt > diff -N sh.mt > *** /sourceware/cvs-tmp/cvsiq6IWP Mon Jan 15 18:01:58 2001 > --- /dev/null Tue May 5 13:32:27 1998 > *************** > *** 1,6 **** > - # Target: Hitachi Super-H with ICE and simulator > - TDEPFILES= sh-tdep.o monitor.o sh3-rom.o remote-e7000.o ser-e7kpc.o dsrec.o solib.o solib-svr4.o > - TM_FILE= tm-linux.h > - > - SIM_OBS = remote-sim.o > - SIM = ../sim/sh/libsim.a > --- 0 ---- > > -- > J.T. Conklin > RedBack Networks >From bje@redhat.com Tue Jan 16 15:02:00 2001 From: Ben Elliston To: Fernando Nasser Cc: Subject: Re: [testsuite] Contribution to testsuite/config Date: Tue, 16 Jan 2001 15:02:00 -0000 Message-id: References: <3A647D4B.4B343299@cygnus.com> X-SW-Source: 2001-01/msg00144.html Content-length: 44 Sure thanks. Commited. Thanks, Ben