Re: [patch] fix for infinite recursion in lookup_symbol

[Fernando Nasser <fnasser@redhat.com>]

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 <kevinb@cygnus.com>
To: Fernando Nasser <fnasser@redhat.com>
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> <fnasser@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 <geoffk@geoffk.org>
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 <geoffk@geoffk.org>

===File ~/patches/cygnus/sim-ppcopen.patch==================
2000-12-29  Geoffrey Keating  <geoffk@redhat.com>

	* 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  <jtc@redback.com>

	* 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 <ac131313@cygnus.com>
To: Nick Duffek <nsd@redhat.com>
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_<module-implementation> 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_<module-name> 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 <ac131313@cygnus.com>
To: Nick Duffek <nsd@redhat.com>
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 <bje@redhat.com>
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  <bje@redhat.com>

	* 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 <fnasser@cygnus.com>
To: Ben Elliston <bje@redhat.com>
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  <bje@redhat.com>
> 
>         * 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 <fnasser@cygnus.com>
To: Michael Snyder <msnyder@redhat.com>
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 <msnyder@cygnus.com>
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  <msnyder@cleaver.cygnus.com>

	* 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 <msnyder@cygnus.com>
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  <msnyder@cleaver.cygnus.com>

	* 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 <nsd@redhat.com>
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. <arch>_gdbarch_init() in <arch>-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(<gdbarch>) and
regs_init_finish() must be attached to <gdbarch>.

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 <ac131313@cygnus.com>
To: Nick Duffek <nsd@redhat.com>
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 <fnasser@redhat.com>
Cc: matthew green <mrg@cygnus.com>, 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 <fnasser@redhat.com> 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 <msnyder@redhat.com>
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  <jtc@redback.com>
> 
>         * 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 <bje@redhat.com>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: <gdb-patches@sources.redhat.com>
Subject: Re: [testsuite] Contribution to testsuite/config
Date: Tue, 16 Jan 2001 15:02:00 -0000
Message-id: <Pine.LNX.4.31.0101170948510.26663-100000@moshpit.cygnus.com>
References: <3A647D4B.4B343299@cygnus.com>
X-SW-Source: 2001-01/msg00144.html
Content-length: 44

   Sure thanks.

Commited.  Thanks,

Ben