Re: RFA: minor watchpoint code cleanup

[Mark Kettenis <kettenis@wins.uva.nl>]

   From: Jim Blandy <jimb@cygnus.com>
   Date: 21 Mar 2000 18:33:30 -0500

   > The reason is that IMHO we should avoid making a variable (`size')
   > serve two puproses at the same time.

   Good suggestion --- done.

   I'm just waiting for Mark's approval.

Approved.

Mark
From ac131313@cygnus.com Tue Mar 21 15:58:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>, GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [MAINT] More additions
Date: Tue, 21 Mar 2000 15:58:00 -0000
Message-id: <38D80C7E.BF2217E8@cygnus.com>
X-SW-Source: 2000-03/msg00451.html
Content-length: 537

Hello,


Michael and Jim are going to share breakpoint code between themselves:

breakpoint.c		Michael Snyder		msnyder@cygnus.com
			Jim Blandy		jimb@cygnus.com


Jonathan Larmour's just managed to exceed his quota of good patch
submissions :-). He's happy to join the write aver approval list:

Jonathan Larmour				jlarmour@redhat.co.uk


David has stepped forward as the SPARC/Solaris and target maintainer:

sparc target		David Taylor		taylor@cygnus.com
Solaris/SPARC native & host
			David Taylor		taylor@cygnus.com


enjoy,
	Andrew
From ac131313@cygnus.com Tue Mar 21 16:10:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Daniel Berlin <dan@cgsoftware.com>
Cc: jtc@redback.com, gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: i386/nbsd.mt, i386nbsd-nat.c
Date: Tue, 21 Mar 2000 16:10:00 -0000
Message-id: <38D80F23.799B5F41@cygnus.com>
References: <Pine.LNX.4.10.10003211547370.15517-100000@propylaea.anduin.com>
X-SW-Source: 2000-03/msg00452.html
Content-length: 516

Daniel Berlin wrote:
> 
> Actually, i have patches to make FreeBSD build native just fine.
> I merged the patches freebsd uses against 4.18 into the current gdb.
> It fails some shared lib tests, but past that, it's fine.
> I can submit them if you like.

The problem I have with the FreeBSD patches is that they have never been
assigned to the FSF by the original author.
I'd have otherwize done the same thing (they are also pretty scrappy)
:-(

Many of the NetBSD changes have the same problem.

	sorry,
		Andrew
From shebs@apple.com Tue Mar 21 17:48:00 2000
From: Stan Shebs <shebs@apple.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Michael Snyder <msnyder@cygnus.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: gdb.texinfo broken?
Date: Tue, 21 Mar 2000 17:48:00 -0000
Message-id: <38D82684.89633B0B@apple.com>
References: <38D6CF69.6844@cygnus.com> <200003211819.NAA12435@indy.delorie.com> <38D7C977.FA3@cygnus.com> <5mitygglxs.fsf@jtc.redbacknetworks.com> <38D7FDD1.D54DE1D8@cygnus.com>
X-SW-Source: 2000-03/msg00453.html
Content-length: 483

Andrew Cagney wrote:
> 
> "J.T. Conklin" wrote:
> 
> > It looks like the changes to the directory entry require the latest
> > makeinfo.  I tried to use makeinfo from texinfo-3.2 and it failed,
> > makeinfo from texinfo-4.0 works.
> 
> >From memory, the possibility of requiring texinfo 4.0 as part of
> building GDB 5 was considered and rejected :-(

Yeah, I have to revert - tried it on one of Apple's MkLinux systems,
which claims to have texinfo 3.9, and it fell down too.

Stan
From jtc@redback.com Tue Mar 21 19:07:00 2000
From: jtc@redback.com (J.T. Conklin)
To: gdb-patches@sourceware.cygnus.com
Subject: RFA: call-ar-st.exp, relax patterns
Date: Tue, 21 Mar 2000 19:07:00 -0000
Message-id: <5mog87g0sx.fsf@jtc.redbacknetworks.com>
X-SW-Source: 2000-03/msg00454.html
Content-length: 8945

I submit the enclosed patch for approval.  As I mentioned some months
ago ( http://sourceware.cygnus.com/ml/gdb/1999-q3/msg00162.html ), the
default pty attributes on NetBSD systems has tabs expanding to spaces
but some of the tests explicitly check for tabs.  I fixed some of the
tests then, but didn't have time to go through all of the failures.
This change relaxes more of expect patterns in call-ar-st.exp.

        --jtc

2000-03-21  J.T. Conklin  <jtc@redback.com> 
 
        * gdb.base/call-ar-st.exp: relax patterns matching tab
          characters.

Index: call-ar-st.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/call-ar-st.exp,v
retrieving revision 1.1.1.7
diff -c -3 -p -r1.1.1.7 call-ar-st.exp
*** call-ar-st.exp	1999/08/23 22:37:37	1.1.1.7
--- call-ar-st.exp	2000/03/22 02:59:09
*************** gdb_expect {
*** 366,372 ****
  if {![target_info exists gdb,skip_float_tests]} {
    send_gdb "print print_small_structs(*struct1, *struct2, *struct3, *struct4, *flags, *flags_combo, *three_char, *five_char, *int_char_combo, *d1, *d2, *d3, *f1, *f2, *f3)\n"
    gdb_expect {
!     -re ".*alpha\[\t\r\n \]+gamma\[\t\r\n \]+epsilon\[\t\r\n \]+alpha\[\t\r\n \]+gamma\[\t\r\n \]+epsilon\[\t\r\n \]+ch1: y\tch2: n\[\t\r\n \]+Contents of three_char_t:\[\t\r\n \]+a\tb\tc\[\t\r\n \]+Contents of five_char_t:\[\t\r\n \]+l\tm\tn\to\tp\[\t\r\n \]+Contents of int_char_combo_t:\[\t\r\n \]+123.*z\[\t\r\n \]+Sum of the 4 struct values and seed :\[\t\r\n \]+52\[\t\r\n \]+Contents of struct1:\[\t\r\n \]+6.*0\[\t\r\n \]+Contents of struct2:\[\t\r\n \]+10.*0\[\t\r\n \]+Contents of struct3:\[\t\r\n \]+12.*0\[\t\r\n \]+Contents of one_double_t:\[\t\r\n \]+10.500000\[\t\r\n \]+Contents of one_double_t:.*-3.340000\[\t\r\n \]+Contents of one_double_t:.*675.091230\[\t\r\n \]+Contents of two_floats_t:.*45.234001.*43.599998\[\t\r\n \]+Contents of two_floats_t:.*78.010002.*122.099998\[\t\r\n \]+Contents of two_floats_t:.*-1232.344971.*-199.210007\[\t\r\n \]+.*$gdb_prompt $" {
        pass "print print_small_structs"
      }
      -re ".*$gdb_prompt $" { fail "print print_small_structs" }
--- 366,372 ----
  if {![target_info exists gdb,skip_float_tests]} {
    send_gdb "print print_small_structs(*struct1, *struct2, *struct3, *struct4, *flags, *flags_combo, *three_char, *five_char, *int_char_combo, *d1, *d2, *d3, *f1, *f2, *f3)\n"
    gdb_expect {
!     -re ".*alpha\[\t\r\n \]+gamma\[\t\r\n \]+epsilon\[\t\r\n \]+alpha\[\t\r\n \]+gamma\[\t\r\n \]+epsilon\[\t\r\n \]+ch1: y.*ch2: n\[\t\r\n \]+Contents of three_char_t:\[\t\r\n \]+a.*b.*c\[\t\r\n \]+Contents of five_char_t:\[\t\r\n \]+l.*m.*n.*o.*p\[\t\r\n \]+Contents of int_char_combo_t:\[\t\r\n \]+123.*z\[\t\r\n \]+Sum of the 4 struct values and seed :\[\t\r\n \]+52\[\t\r\n \]+Contents of struct1:\[\t\r\n \]+6.*0\[\t\r\n \]+Contents of struct2:\[\t\r\n \]+10.*0\[\t\r\n \]+Contents of struct3:\[\t\r\n \]+12.*0\[\t\r\n \]+Contents of one_double_t:\[\t\r\n \]+10.500000\[\t\r\n \]+Contents of one_double_t:.*-3.340000\[\t\r\n \]+Contents of one_double_t:.*675.091230\[\t\r\n \]+Contents of two_floats_t:.*45.234001.*43.599998\[\t\r\n \]+Contents of two_floats_t:.*78.010002.*122.099998\[\t\r\n \]+Contents of two_floats_t:.*-1232.344971.*-199.210007\[\t\r\n \]+.*$gdb_prompt $" {
        pass "print print_small_structs"
      }
      -re ".*$gdb_prompt $" { fail "print print_small_structs" }
*************** if {![target_info exists gdb,skip_float_
*** 461,467 ****
      setup_xfail "sparc*-*-solaris*"
      send_gdb "print print_small_structs(struct1, struct2, struct3, struct4, flags, flags_combo, three_char, five_char, int_char_combo, d1, d2, d3, f1, f2, f3)\n"
      gdb_expect {
! 	-re ".*alpha${ws}gamma${ws}epsilon${ws}alpha${ws}gamma${ws}epsilon${ws}ch1: y\tch2: n${ws}Contents of three_char_t:${ws}a\tb\tc${ws}Contents of five_char_t:${ws}l\tm\tn\to\tp${ws}Contents of int_char_combo_t:${ws}123.*z${ws}Sum of the 4 struct values and seed :${ws}52${ws}Contents of struct1:${ws}6.*0${ws}Contents of struct2:${ws}10.*0${ws}Contents of struct3:${ws}12.*0${ws}Contents of one_double_t:${ws}10.500000${ws}Contents of one_double_t:${ws}-3.340000${ws}Contents of one_double_t:${ws}675.091230${ws}Contents of two_floats_t:${ws}45.234001.*43.599998${ws}Contents of two_floats_t:${ws}78.010002.*122.099998${ws}Contents of two_floats_t:${ws}-1232.344971.*-199.210007${ws}.*$gdb_prompt $" {
  	    pass "print print_small_structs from print_long_arg_list"
  	}
  	-re ".*$gdb_prompt $" { fail "print print_small_structs from print_long_arg_list" }
--- 461,467 ----
      setup_xfail "sparc*-*-solaris*"
      send_gdb "print print_small_structs(struct1, struct2, struct3, struct4, flags, flags_combo, three_char, five_char, int_char_combo, d1, d2, d3, f1, f2, f3)\n"
      gdb_expect {
! 	-re ".*alpha${ws}gamma${ws}epsilon${ws}alpha${ws}gamma${ws}epsilon${ws}ch1: y.*ch2: n${ws}Contents of three_char_t:${ws}a.*b.*c${ws}Contents of five_char_t:${ws}l.*m.*n.*o.*p${ws}Contents of int_char_combo_t:${ws}123.*z${ws}Sum of the 4 struct values and seed :${ws}52${ws}Contents of struct1:${ws}6.*0${ws}Contents of struct2:${ws}10.*0${ws}Contents of struct3:${ws}12.*0${ws}Contents of one_double_t:${ws}10.500000${ws}Contents of one_double_t:${ws}-3.340000${ws}Contents of one_double_t:${ws}675.091230${ws}Contents of two_floats_t:${ws}45.234001.*43.599998${ws}Contents of two_floats_t:${ws}78.010002.*122.099998${ws}Contents of two_floats_t:${ws}-1232.344971.*-199.210007${ws}.*$gdb_prompt $" {
  	    pass "print print_small_structs from print_long_arg_list"
  	}
  	-re ".*$gdb_prompt $" { fail "print print_small_structs from print_long_arg_list" }
*************** init_bit_flags_combo \\(bit_flags_combo=
*** 491,497 ****
  #call print_bit_flags_combo(*bit_flags_combo)
  send_gdb "print print_bit_flags_combo(*bit_flags_combo)\n"
  gdb_expect {
!     -re ".*alpha.*gamma.*epsilon.*ch1: y\tch2: n.*$gdb_prompt $" {
          pass "print print_bit_flags_combo from init_bit_flags_combo"
        }
      -re ".*$gdb_prompt $" { fail "print print_bit_flags_combo from init_bit_flags_combo" }
--- 491,497 ----
  #call print_bit_flags_combo(*bit_flags_combo)
  send_gdb "print print_bit_flags_combo(*bit_flags_combo)\n"
  gdb_expect {
!     -re ".*alpha.*gamma.*epsilon.*ch1: y.*ch2: n.*$gdb_prompt $" {
          pass "print print_bit_flags_combo from init_bit_flags_combo"
        }
      -re ".*$gdb_prompt $" { fail "print print_bit_flags_combo from init_bit_flags_combo" }
*************** if {$hp_aCC_compiler} {setup_xfail "hppa
*** 518,524 ****
  if {![target_info exists gdb,skip_float_tests]} {
    send_gdb "print print_long_arg_list(a, b, c, d, e, f, *struct1, *struct2, *struct3, *struct4, *flags, *flags_combo, *three_char, *five_char, *int_char_combo, *d1, *d2, *d3, *f1, *f2, *f3)\n"
    gdb_expect {
!     -re ".*double : 22.220000.*double : 33.333000.*int : 0.*int : -25.*int : 100.*int : 2345.*alpha.*gamma.*epsilon.*ch1: y\tch2: n.*Contents of three_char_t:.*x\ty\tz.*Contents of five_char_t:.*h\te\tl\tl\to.*Contents of int_char_combo_t:.*123\tz.*Sum of the 4 struct values and seed :.*52.*Contents of struct1:.*6\[ \]+0.*Contents of struct2:.*10\[ \]+0.*Contents of struct3:.*12.*0.*Contents of one_double_t:\[ \n\r\t\]+1.111110\[ \n\r\t\]+Contents of one_double_t:\[ \n\r\t\]+-345.340000\[ \n\r\t\]+Contents of one_double_t:\[ \n\r\t\]+546464.200000\[ \n\r\t\]+Contents of two_floats_t:\[ \n\r\t\]+0.234000\t453.100006\[ \n\r\t\]+Contents of two_floats_t:\[ \n\r\t\]+78.345001\t23.090000\[ \n\r\t\]+Contents of two_floats_t:\[ \n\r\t\]+-2.345000\t1.000000.*$gdb_prompt $" {
        pass "print print_long_arg_list"
      }
      -re ".*$gdb_prompt $" { fail "print print_long_arg_list" }
--- 518,524 ----
  if {![target_info exists gdb,skip_float_tests]} {
    send_gdb "print print_long_arg_list(a, b, c, d, e, f, *struct1, *struct2, *struct3, *struct4, *flags, *flags_combo, *three_char, *five_char, *int_char_combo, *d1, *d2, *d3, *f1, *f2, *f3)\n"
    gdb_expect {
!     -re ".*double : 22.220000.*double : 33.333000.*int : 0.*int : -25.*int : 100.*int : 2345.*alpha.*gamma.*epsilon.*ch1: y.*ch2: n.*Contents of three_char_t:.*x.*y.*z.*Contents of five_char_t:.*h.*e.*l.*l.*o.*Contents of int_char_combo_t:.*123.*z.*Sum of the 4 struct values and seed :.*52.*Contents of struct1:.*6\[ \]+0.*Contents of struct2:.*10\[ \]+0.*Contents of struct3:.*12.*0.*Contents of one_double_t:\[ \n\r\t\]+1.111110\[ \n\r\t\]+Contents of one_double_t:\[ \n\r\t\]+-345.340000\[ \n\r\t\]+Contents of one_double_t:\[ \n\r\t\]+546464.200000\[ \n\r\t\]+Contents of two_floats_t:\[ \n\r\t\]+0.234000.*453.100006\[ \n\r\t\]+Contents of two_floats_t:\[ \n\r\t\]+78.345001.*23.090000\[ \n\r\t\]+Contents of two_floats_t:\[ \n\r\t\]+-2.345000.*1.000000.*$gdb_prompt $" {
        pass "print print_long_arg_list"
      }
      -re ".*$gdb_prompt $" { fail "print print_long_arg_list" }


-- 
J.T. Conklin
RedBack Networks
From ac131313@cygnus.com Tue Mar 21 20:21:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jimmy Guo <guo@cup.hp.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: Initialization of hpux_threads
Date: Tue, 21 Mar 2000 20:21:00 -0000
Message-id: <38D849A1.F5F706A@cygnus.com>
References: <Pine.LNX.4.10.10003211552360.31590-100000@hpcll168.cup.hp.com>
X-SW-Source: 2000-03/msg00455.html
Content-length: 1125

Jimmy Guo wrote:
> 
> I was looking at an old source tree and didn't see its 'revival'.
> Yes it is some setup to solve the kinds of problem you mentioned.
> But any other usage of it will only introduce multiple calls to
> a _initialize_* routine.
> 
> The initializer in hpux-thread.c is just one of these cases.  They're
> mostly fixed as of today's tree except for a remaining one -
> remote-nrom.c.

Thanks,  I've applied the attatched.

	Andrew
Wed Mar 22 15:09:34 2000  Andrew Cagney  <cagney@b1.cygnus.com>

	* configure.in (CONFIG_INITS): Do not append remote-nrom.c

Index: configure.in
===================================================================
RCS file: /cvs/src/src/gdb/configure.in,v
retrieving revision 1.12
diff -p -r1.12 configure.in
*** configure.in	2000/03/20 06:41:24	1.12
--- configure.in	2000/03/22 04:15:36
*************** esac])
*** 447,453 ****
  if test "${enable_netrom}" = "yes"; then
  	CONFIG_OBS="${CONFIG_OBS} remote-nrom.o" 
          CONFIG_SRCS="${CONFIG_SRCS} remote-nrom.c"
- 	CONFIG_INITS="${CONFIG_INITS} remote-nrom.c"
  fi
  
  AC_ARG_ENABLE(build-warnings,
--- 447,452 ----
From ac131313@cygnus.com Tue Mar 21 20:25:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Cc: GDB Discussion <gdb@sourceware.cygnus.com>
Subject: [Maint] Second testsuite maintainer
Date: Tue, 21 Mar 2000 20:25:00 -0000
Message-id: <38D84B37.B90E15AB@cygnus.com>
X-SW-Source: 2000-03/msg00456.html
Content-length: 282

Another addition:

Add Fernando to list of testsuite maintainers.

testsuite	 	Stan Shebs		shebs@apple.com
			Fernando Nasser		fnasser@cygnus.com
  hp tests (gdb.hp)	*Jimmy Guo	 adl-debugger-wdb-merge-guru@cup.hp.com
  Java tests (gdb.java)	Anthony Green 		green@cygnus.com

Andrew
From ac131313@cygnus.com Tue Mar 21 21:38:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Michael Snyder <msnyder@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] Document the ThreadInfo remote protocol queries
Date: Tue, 21 Mar 2000 21:38:00 -0000
Message-id: <38D85C2F.FF89881D@cygnus.com>
References: <200003202316.PAA07888@cleaver.cygnus.com> <38D6FCE2.EBD9830F@cygnus.com> <38D7C38C.6CB0@cygnus.com>
X-SW-Source: 2000-03/msg00457.html
Content-length: 2117

Michael Snyder wrote:

> > An additional note on these versions of thread queries.  While
> > significantly better than the ``qL'' packet these commands still have
> > problems.  I'll add notes expanding on this.  Briefly, however:
> >
> >         o       Per the query packet spec, they should be
> >                 prefixed with a UCASE letter if they
> >                 are to be official GDB packets.
> >
> >         o       The ``sThread..'' command assumes
> >                 that the GDB protocol is reliable
> >                 which it is not.  GDB can re-issue
> >                 a ``sThread'' request and this can
> >                 lead to GDB and the target falling
> >                 out of sync.
> 
> How about if the 'sThread' request were to be suffixed with
> the last thread ID received?

I was thinking of deprecating fThreadInfo and sThreadInfo and having gdb
try:

	qThreadInfo
	qThreadInfo,<sentinal>

Where sentinal could be <last-thread-id> index (counting from zero) for
next threads, or anything else.

Given ``sThreadInfo'' is in the field, we can't change it.


> > with regard to ``qfThreadExtraInfo''.  As far as I know its not been
> > deployed in the field.  Is there any reason to not name it correctly
> > from the start  (``qThreadExtraInfo'')?
> 
> Only that it conflicts with the tracepoint messages,
> which all begin with qT (see tracepoint.c).

I don't think that is a problem.  The protocol requires:

@tab @code{q}@var{query}
@tab
Request info about @var{query}.  In general @value{GDBN} @var{query}'s
have a leading upper case letter.  Custom vendor queries should use a
company prefix (in lower case) ex: @samp{qfsf.var}.  @var{query} may
optionally be followed by a @samp{,} or @samp{;} separated list.  Stubs
must ensure that they match the full @var{query} name.

The last sentence is ment to ensure that the target's query handling
code matches using something like:
	strcmp (packet, "qThreadInfo")
instead of
	packet[0] == 'q' && packet[1] == 'T' && packet[7] == 'I'


Should ``C'' also be suceeded by something like ``qThread''?  Is ``C''
still used?

	Andrew
From eliz@delorie.com Wed Mar 22 00:58:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Mark Kettenis <kettenis@wins.uva.nl>, gdb-patches@sourceware.cygnus.com
Subject: Re: Linux sigtramp detection code moved to its proper place
Date: Wed, 22 Mar 2000 00:58:00 -0000
Message-id: <200003220858.DAA12990@indy.delorie.com>
References: <200003201529.KAA10589@indy.delorie.com> <38D73C78.4B2B3562@cygnus.com>
X-SW-Source: 2000-03/msg00458.html
Content-length: 2641

> Is there anything that the nightly snapshots (short term) and/or
> testsuite (medium/long term) can do to ensure that the relevant
> djgpp files are always up-to-date?

As a matter of fact, there is.  I have todo items for the following
issues:

  - The file config/djgpp/fnchange.lst needs to be updated to include
    the exact version in the file names it maps.  Specifically, that
    file consists of lines which look like this:

      gdb-0321/foo/bar/long-name-foo.c gdb-0321/foo/bar/short-foo.c

    (When DJTAR sees this line, it renames the file whose name is on
    the left to what's on the right.)

    The "gdb-0312" part should be replaced with the actual name of the
    directory which the distribution creates when unpacked, and that
    name includes the version of the snapshot/release.

    What I was thinking was to provide a template whose lines will say
    this:

      gdb-@VER@/foo/bar/long-name-foo.c gdb-@VER@/foo/bar/short-foo.c

    and run Sed on it inside the commands used to tar the
    distribution, to replace that with the actual version (taken from
    the Makefile, for example).

  - If the long names which clash after 8+3 truncation are to stay
    with us for Quite A While (tm), it might make sense to have some
    script or program that will update fnchange.lst whenever a new
    file is added that clashes with some other file name, but is not
    yet covered in fnchange.lst.  Assuming that the files which get
    added are not required for the DJGPP build (since those must
    *never* clash with other file names), what we need is to add an
    entry like this:

      gdb-@VER@/foo/bar/new-long-name-foo.bar

    When DJTAR sees such a line, it skips the named file.

    This looks like a job for a Perl script.  Unfortunately, Perl for
    me is a read-only language.  I could write a C program to do this,
    if this is acceptable, though.

Comments and ideas are welcome.

> As a suggestion from left field, I've wondered if gdb.base/selftest.exp
> should be moved to gdb.wb/selftest.exp (wb == white box) so that people
> can freely add additional white box tests to GDB.  Checking consistency
> between config/djgpp/<that-file> and the GDB sources could be part of
> that testsuite.

Does that mean that you always run the test suite before preparing the
snapshots?  If so, how do you know whether a certain new failure is
grave enough to prevent you from making the snapshot?  I mean, if the
test for consistency in config/djgpp/<that-file> were added, and it
failed, how would you know that this is not some minor regression
(which I assume do happen in other parts of GDB)?
From eliz@delorie.com Wed Mar 22 01:30:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: msnyder@cygnus.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] Running the inferior from breakpoint commands
Date: Wed, 22 Mar 2000 01:30:00 -0000
Message-id: <200003220930.EAA13024@indy.delorie.com>
References: <200003120759.CAA24402@indy.delorie.com> <200003151624.LAA01228@indy.delorie.com> <38D7F31D.1827@cygnus.com>
X-SW-Source: 2000-03/msg00459.html
Content-length: 2020

> 	Any
> 	other commands in the command list are ignored, after
> 	a command that resumes execution.
> 
> Note the last sentence.  So despite the fact that the 
> testsuite seems to imply that this should work, it is
> not expected to.  I have no idea what that test is 
> doing in there.  The commands-on-breakpoint behavior
> is NOT intended to be recursive.

Yes, somebody already pointed out that this appears to be a documented
limitation.  Unfortunately, this info came after I already did the
changes and posted them; my original question when I first discovered
the problem remained unanswered...

(I did look in the manual, but since the snippet you cited isn't
indexed, I didn't find it.  [Yes, I will submit a manual change to add
an index entry.])

To me, the fact that the test suite tried to do this was a sign that
it was supposed to work.

As an aside: is there any place I can find the list of tests which
fail, and on what systems do they fail?

> If you seriously want to undertake this project, we can
> work on a list of criteria that should be tested (things
> that can go wrong).

I will put it on my todo (thanks for the list of things to test; some
of them were already tested, I just didn't report it).  I would like
at least to probe the issues, to get a feeling how badly broken is
what I did ;-).

> On top of that, I have grave concerns about being able
> to correctly save and restore all of the internal
> debugger state necessary to make this work (the
> infrun execution state, the expression chain, etc.)

Err... I'm not sure this should be of concern here (but perhaps I
don't see the subtle issues clearly enough): if the breakpoint
commands change any of these global entities, I think the user expects
the changes to be visible after these commands are processed.  For
example, if the commands delete the breakpoint where you stopped, the
user will expect the breakpoint to remain deleted after that (the
changes I submitted do handle this specific case).  Am I missing
something?
From kettenis@wins.uva.nl Wed Mar 22 01:49:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: gdb-patches@sourceware.cygnus.com
Cc: jtc@redback.com
Subject: [PATCH] Restructuring i386-tdep.c:i386_extract_return_value()
Date: Wed, 22 Mar 2000 01:49:00 -0000
Message-id: <200003220949.e2M9nl001746@delius.kettenis.local>
X-SW-Source: 2000-03/msg00460.html
Content-length: 6153

Hi,

I checked in the attached patch.  This is one of the patches I
discussed two weeks ago, which makes i386_extract_return_value() do
the right thing for most of the supported i386 targets.  Some targets
(for example those that use tm-i386v.h) still redefine
EXTRACT_RETURN_VALUE, so they don't take advantage of this
improvement.  I'll deal with that later.

Mark


2000-03-22  Mark Kettenis  <kettenis@gnu.org>

	* config/i386/tm-i386aix.h (I386_AIX_TARGET): Remove.
	* config/i386/tm-linux.h (LOW_RETURN_REGNUM, HIGH_RETURN_REGNUM):
	Remove
	* i386-tdep.c (LOW_RETURN_REGNUM, HIGH_RETURN_REGNUM): New defines.
	(i386_extract_return_value): Rewritten.  Correctly support all
	floating-point types and large integer types on targets that use
	the standard i386 GDB register layout and return floating-point
	values in the FPU.


Index: config/i386/tm-i386aix.h
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/tm-i386aix.h,v
retrieving revision 1.2
diff -u -p -r1.2 tm-i386aix.h
--- config/i386/tm-i386aix.h	2000/03/02 15:44:27	1.2
+++ config/i386/tm-i386aix.h	2000/03/22 09:41:10
@@ -30,14 +30,6 @@
 #define I386 1
 #endif
 
-/* FIXME: kettenis/2000-03-02: This is used in
-   i386-tdep.c:i386_extract_return_value(), and will be remove once
-   I've fixed that.  Meanwhile don't use it for any other purpose
-   please!  */
-#ifndef I386_AIX_TARGET
-#define I386_AIX_TARGET 1
-#endif
-
 /* AIX/i386 has FPU support.  However, the native configuration (which
    is the only supported configuration) doesn't make the FPU control
    registers available.  Override the appropriate symbols such that
Index: config/i386/tm-linux.h
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/tm-linux.h,v
retrieving revision 1.4
diff -u -p -r1.4 tm-linux.h
--- config/i386/tm-linux.h	2000/03/16 22:46:30	1.4
+++ config/i386/tm-linux.h	2000/03/22 09:41:10
@@ -30,9 +30,6 @@
 #include "i386/tm-i386.h"
 #include "tm-linux.h"
 
-#define LOW_RETURN_REGNUM 0	/* holds low four bytes of result */
-#define HIGH_RETURN_REGNUM 2	/* holds high four bytes of result */
-
 /* This should probably move to tm-i386.h.  */
 #define TARGET_LONG_DOUBLE_BIT 80
 
Index: i386-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/i386-tdep.c,v
retrieving revision 1.7
diff -u -p -r1.7 i386-tdep.c
--- i386-tdep.c	2000/03/16 22:46:26	1.7
+++ i386-tdep.c	2000/03/22 09:41:10
@@ -698,56 +698,66 @@ get_longjmp_target (pc)
 
 #endif /* GET_LONGJMP_TARGET */
 
+/* These registers are used for returning integers (and on some
+   targets also for returning `struct' and `union' values when their
+   size and alignment match an integer type.  */
+#define LOW_RETURN_REGNUM 0	/* %eax */
+#define HIGH_RETURN_REGNUM 2	/* %edx */
+
+/* Extract from an array REGBUF containing the (raw) register state, a
+   function return value of TYPE, and copy that, in virtual format,
+   into VALBUF.  */
+
 void
-i386_extract_return_value (type, regbuf, valbuf)
-     struct type *type;
-     char regbuf[REGISTER_BYTES];
-     char *valbuf;
+i386_extract_return_value (struct type *type, char *regbuf, char *valbuf)
 {
-  /* On AIX, i386 GNU/Linux and DJGPP, floating point values are
-     returned in floating point registers.  */
-  /* FIXME: cagney/2000-02-29: This function needs to be rewritten
-     using multi-arch. Please don't keep adding to this #ifdef
-     spaghetti. */
-#if defined(I386_AIX_TARGET) || defined(I386_GNULINUX_TARGET) || defined(I386_DJGPP_TARGET)
+  int len = TYPE_LENGTH (type);
+
   if (TYPE_CODE_FLT == TYPE_CODE (type))
     {
-      double d;
-      /* 387 %st(0), gcc uses this */
-      floatformat_to_double (&floatformat_i387_ext,
-#if defined(FPDATA_REGNUM)
-			     &regbuf[REGISTER_BYTE (FPDATA_REGNUM)],
-#else /* !FPDATA_REGNUM */
-			     &regbuf[REGISTER_BYTE (FP0_REGNUM)],
-#endif /* FPDATA_REGNUM */
+      if (NUM_FREGS == 0)
+	{
+	  warning ("Cannot find floating-point return value.");
+	  memset (valbuf, 0, len);
+	}
 
-			     &d);
-      store_floating (valbuf, TYPE_LENGTH (type), d);
+      /* Floating-point return values can be found in %st(0).  */
+      if (len == TARGET_LONG_DOUBLE_BIT / TARGET_CHAR_BIT
+	  && TARGET_LONG_DOUBLE_FORMAT == &floatformat_i387_ext)
+	{
+	  /* Copy straight over, but take care of the padding.  */
+	  memcpy (valbuf, &regbuf[REGISTER_BYTE (FP0_REGNUM)],
+		  FPU_REG_RAW_SIZE);
+	  memset (valbuf + FPU_REG_RAW_SIZE, 0, len - FPU_REG_RAW_SIZE);
+	}
+      else
+	{
+	  /* Convert the extended floating-point number found in
+             %st(0) to the desired type.  This is probably not exactly
+             how it would happen on the target itself, but it is the
+             best we can do.  */
+	  DOUBLEST val;
+	  floatformat_to_doublest (&floatformat_i387_ext,
+				   &regbuf[REGISTER_BYTE (FP0_REGNUM)], &val);
+	  store_floating (valbuf, TYPE_LENGTH (type), val);
+	}
     }
   else
-#endif /* I386_AIX_TARGET || I386_GNULINUX_TARGET || I386_DJGPP_TARGET */
     {
-#if defined(LOW_RETURN_REGNUM)
-      int len = TYPE_LENGTH (type);
       int low_size = REGISTER_RAW_SIZE (LOW_RETURN_REGNUM);
       int high_size = REGISTER_RAW_SIZE (HIGH_RETURN_REGNUM);
 
       if (len <= low_size)
-	memcpy (valbuf, regbuf + REGISTER_BYTE (LOW_RETURN_REGNUM), len);
+	memcpy (valbuf, &regbuf[REGISTER_BYTE (LOW_RETURN_REGNUM)], len);
       else if (len <= (low_size + high_size))
 	{
 	  memcpy (valbuf,
-		  regbuf + REGISTER_BYTE (LOW_RETURN_REGNUM),
-		  low_size);
+		  &regbuf[REGISTER_BYTE (LOW_RETURN_REGNUM)], low_size);
 	  memcpy (valbuf + low_size,
-		  regbuf + REGISTER_BYTE (HIGH_RETURN_REGNUM),
-		  len - low_size);
+		  &regbuf[REGISTER_BYTE (HIGH_RETURN_REGNUM)], len - low_size);
 	}
       else
-	error ("GDB bug: i386-tdep.c (i386_extract_return_value): Don't know how to find a return value %d bytes long", len);
-#else /* !LOW_RETURN_REGNUM */
-      memcpy (valbuf, regbuf, TYPE_LENGTH (type));
-#endif /* LOW_RETURN_REGNUM */
+	internal_error ("Cannot extract return value of %d bytes long.", len);
     }
 }
 
From eliz@delorie.com Wed Mar 22 02:32:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: jtc@redback.com
Cc: msnyder@cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: gdb.texinfo broken?
Date: Wed, 22 Mar 2000 02:32:00 -0000
Message-id: <200003221032.FAA13070@indy.delorie.com>
References: <38D6CF69.6844@cygnus.com> <200003211819.NAA12435@indy.delorie.com> <38D7C977.FA3@cygnus.com> <5mitygglxs.fsf@jtc.redbacknetworks.com>
X-SW-Source: 2000-03/msg00461.html
Content-length: 488

> It looks like the changes to the directory entry require the latest
> makeinfo.  I tried to use makeinfo from texinfo-3.2 and it failed,
> makeinfo from texinfo-4.0 works.

What directory entry?  If you mean @direntry and @dircategory, then
they were introduced in Texinfo 3.8, so they are not the problem.

I have several old versions of Texinfo on my machine, so will look
into these problems ASAP (since it might be my fault: the error
messages mention some of the lines I changed).
From ac131313@cygnus.com Wed Mar 22 03:23:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: Mark Kettenis <kettenis@wins.uva.nl>, gdb-patches@sourceware.cygnus.com
Subject: Re: Linux sigtramp detection code moved to its proper place
Date: Wed, 22 Mar 2000 03:23:00 -0000
Message-id: <38D8ACDE.DA82F9E6@cygnus.com>
References: <200003201529.KAA10589@indy.delorie.com> <38D73C78.4B2B3562@cygnus.com> <200003220858.DAA12990@indy.delorie.com>
X-SW-Source: 2000-03/msg00462.html
Content-length: 1013

Eli Zaretskii wrote:

> > As a suggestion from left field, I've wondered if gdb.base/selftest.exp
> > should be moved to gdb.wb/selftest.exp (wb == white box) so that people
> > can freely add additional white box tests to GDB.  Checking consistency
> > between config/djgpp/<that-file> and the GDB sources could be part of
> > that testsuite.
> 
> Does that mean that you always run the test suite before preparing the
> snapshots?  If so, how do you know whether a certain new failure is
> grave enough to prevent you from making the snapshot?  I mean, if the
> test for consistency in config/djgpp/<that-file> were added, and it
> failed, how would you know that this is not some minor regression
> (which I assume do happen in other parts of GDB)?

No a snapshot is just that.  No guarentee that it will even build :-/

The reason for suggesting a check in the testsuite was that someone
adding a new file would hopefully run the testsuite after adding their
badly named file and notice the failure.

	Andrew
From fnasser@redhat.com Wed Mar 22 05:09:00 2000
From: Fernando Nasser <fnasser@redhat.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: [Maint] Second testsuite maintainer
Date: Wed, 22 Mar 2000 05:09:00 -0000
Message-id: <38D8C5BA.20C4B77@redhat.com>
References: <38D84B37.B90E15AB@cygnus.com>
X-SW-Source: 2000-03/msg00463.html
Content-length: 772

Are you still going from the backlog from the Linux conference? :-)

Ben said it was OK and that he met the RedHat mkting people from the
North of Australia...

Andrew Cagney wrote:
> 
> Another addition:
> 
> Add Fernando to list of testsuite maintainers.
> 
> testsuite               Stan Shebs              shebs@apple.com
>                         Fernando Nasser         fnasser@cygnus.com
>   hp tests (gdb.hp)     *Jimmy Guo       adl-debugger-wdb-merge-guru@cup.hp.com
>   Java tests (gdb.java) Anthony Green           green@cygnus.com
> 
> Andrew

-- 
Fernando Nasser
Red Hat, Inc. - Toronto                 E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299
From fnasser@redhat.com Wed Mar 22 05:11:00 2000
From: Fernando Nasser <fnasser@redhat.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: [Maint] Second testsuite maintainer
Date: Wed, 22 Mar 2000 05:11:00 -0000
Message-id: <38D8C648.3FE00B1C@redhat.com>
References: <38D84B37.B90E15AB@cygnus.com> <38D8C5BA.20C4B77@redhat.com>
X-SW-Source: 2000-03/msg00464.html
Content-length: 307

Sorry folks.

That was a personal message and I pressed the wrong button by mistake. 
:-(


-- 
Fernando Nasser
Red Hat, Inc. - Toronto                 E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299
From eliz@delorie.com Wed Mar 22 08:55:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: Michael Snyder <msnyder@cygnus.com>
Cc: jtc@redback.com (J.T. Conklin), gdb-patches@sourceware.cygnus.com
Subject: Re: gdb.texinfo broken? 
Date: Wed, 22 Mar 2000 08:55:00 -0000
Message-id: <200003221655.LAA14175@indy.delorie.com>
References: <38D6CF69.6844@cygnus.com> <200003211819.NAA12435@indy.delorie.com> <5mitygglxs.fsf@jtc.redbacknetworks.com>
X-SW-Source: 2000-03/msg00465.html
Content-length: 4870

< 38D7C977.FA3@cygnus.com > < 5mitygglxs.fsf@jtc.redbacknetworks.com >

> >>>>> "Michael" == Michael Snyder <msnyder@cygnus.com> writes:
> Michael> %] msnyder<2>% make gdb.info
> Michael> makeinfo -I
> Michael> /cleaver/blade/msnyder/sourceware/src/gdb/doc/../../readline/doc -I
> Michael> /cleaver/blade/msnyder/sourceware/src/gdb/doc -o ./gdb.info gdb.texinfo
> Michael> Making info file `./gdb.info' from `gdb.texinfo'.
> Michael> gdb.texinfo:113: No matching `@end ifnottex'.
> Michael> gdb.texinfo:156: Unmatched `@end'.
> 
> It looks like the changes to the directory entry require the latest
> makeinfo.  I tried to use makeinfo from texinfo-3.2 and it failed,
> makeinfo from texinfo-4.0 works.

Okay, I think I know what's going on with gdb.texinfo and old versions
of Texinfo.

First, I'm guessing that Michael Snyder didn't "cvs up annotate.texi".
The old version was written as a separate manual, so it had its own
Top node etc.  The new gdb.texinfo @include's annotate.texi, so
Michael gets error messages about multiple Top nodes etc..  When I
introduced the changes into gdb.texinfo to include the Annotations
chapter, I changed annotate.texi accordingly, to avoid all these
problems.

This leaves us with two error messages cited above:

 gdb.texinfo:113: No matching `@end ifnottex'.
 gdb.texinfo:156: Unmatched `@end'.

These come from Texinfo 3.11 and later (I tried 3.12; I don't have
3.11 on my disk), which is where @ifnottex was introduced.  Texinfo
3.9 and earlier doesn't grok @ifnottex at all, and Texinfo 4.0
converts the file without any problems.

The problem with @ifnottex in Texinfo 3.12 are actually a
bug/misfeature in that version: conditionals such as @ifnottex cannot
span node boundaries.  Here's a ChangeLog entry from the latest
Texinfo distribution:

  Sun Nov 29 17:12:35 1998  Karl Berry  <karl@gnu.org>

	  [...]
	  * makeinfo/insertion.c (discard_insertions): Let any conditional
	  cross node boundary.  (So the @top node can be wrapped
	  in @ifnottex, for example.)

This was done during the (long) pretest of Texinfo 4.0.

Since we decided not to depend on Texinfo 4.0, it seems we have 2
alternatives:

  - Toss @ifnottex and go back to using @ifinfo.  This will disallow
    producing the manual in the HTML format (only possible with
    Texinfo 4.0).

  - Duplicate the offending Top node, once wrapped with @ifinfo, the
    other time wrapped with @ifhtml.  This works for me with Texinfo
    3.12 and 4.0.  The patch for this alternative is below.

I recommend to use the second alternative, even though it's kludgey.

Note that if we use @ifnottex, we need to require Texinfo 3.11 or
later; Texinfo 3.9 will not work.

--- gdb/doc/gdb.t~2	Wed Mar 22 12:49:54 2000
+++ gdb/doc/gdb.texinfo	Wed Mar 22 18:02:48 2000
@@ -110,7 +110,7 @@
 @end titlepage
 @page
 
-@ifnottex
+@ifinfo
 @node Top
 @top Debugging with @value{GDBN}
 
@@ -153,7 +153,52 @@
 * Index::                       Index
 @end menu
 
-@end ifnottex
+@end ifinfo
+
+@ifhtml
+@node Top
+@top Debugging with @value{GDBN}
+
+This file describes @value{GDBN}, the @sc{gnu} symbolic debugger.
+
+This is the @value{EDITION} Edition, @value{DATE}, for @value{GDBN} Version 
+@value{GDBVN}.
+
+Copyright (C) 1988-1999 Free Software Foundation, Inc.
+@menu
+* Summary::                     Summary of @value{GDBN}
+* Sample Session::              A sample @value{GDBN} session
+
+* Invocation::                  Getting in and out of @value{GDBN}
+* Commands::                    @value{GDBN} commands
+* Running::                     Running programs under @value{GDBN}
+* Stopping::                    Stopping and continuing
+* Stack::                       Examining the stack
+* Source::                      Examining source files
+* Data::                        Examining data
+
+* Languages::                   Using @value{GDBN} with different languages
+
+* Symbols::                     Examining the symbol table
+* Altering::                    Altering execution
+* GDB Files::                   @value{GDBN} files
+* Targets::                     Specifying a debugging target
+* Configurations::              Configuration-specific information
+* Controlling GDB::             Controlling @value{GDBN}
+* Sequences::                   Canned sequences of commands
+* Emacs::                       Using @value{GDBN} under @sc{gnu} Emacs
+* Annotations::                 @value{GDBN}'s annotations interface.
+
+* GDB Bugs::                    Reporting bugs in @value{GDBN}
+* Formatting Documentation::    How to format and print @value{GDBN} documentation
+
+* Command Line Editing::        Command Line Editing
+* Using History Interactively:: Using History Interactively
+* Installing GDB::              Installing GDB
+* Index::                       Index
+@end menu
+
+@end ifhtml
 
 @node Summary
 @unnumbered Summary of @value{GDBN}
From eliz@delorie.com Wed Mar 22 10:10:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: Jim Blandy <jimb@zwingli.cygnus.com>
Cc: hjl@lucon.org, gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Problems with hardware watchpoint on ia32.
Date: Wed, 22 Mar 2000 10:10:00 -0000
Message-id: <200003221806.NAA14225@indy.delorie.com>
References: <20000307132401.A20282@valinux.com> <200003081008.FAA16481@indy.delorie.com> <20000308084304.A3150@lucon.org> <200003091210.HAA19857@indy.delorie.com> <npya7c6zn7.fsf@zwingli.cygnus.com>
X-SW-Source: 2000-03/msg00466.html
Content-length: 724

> Eli's test of the value's type is incorrect if the watch expression
> contains a structure comparison, like (foo == bar) || (something
> else), where foo and bar are structures.  In that case, there will be
> a value of type "struct", not at the end of the value list, but which
> should be watched in its entirety.

Errr... do you have an actual example program where this happens?

I seem to be unable to reproduce the problem, at least in a C program:
whenever I say "watch foo == bar" (where foo and bar are structs), GDB
curses thusly:

	Structure has no component named operator==.

Am I missing something?

In case it matters, I tested this with a DJGPP-compiled program; DJGPP
by default uses COFF debugging info.
From msnyder@cygnus.com Wed Mar 22 10:11:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] Document the ThreadInfo remote protocol queries
Date: Wed, 22 Mar 2000 10:11:00 -0000
Message-id: <38D90CE6.4D18@cygnus.com>
References: <200003202316.PAA07888@cleaver.cygnus.com> <38D6FCE2.EBD9830F@cygnus.com> <38D7C38C.6CB0@cygnus.com> <38D85C2F.FF89881D@cygnus.com>
X-SW-Source: 2000-03/msg00467.html
Content-length: 130

Andrew Cagney wrote:

> Should ``C'' also be suceeded by something like ``qThread''?  Is ``C''
> still used?

'qC' is still used.
From msnyder@cygnus.com Wed Mar 22 10:20:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] Running the inferior from breakpoint commands
Date: Wed, 22 Mar 2000 10:20:00 -0000
Message-id: <38D90EEC.1566@cygnus.com>
References: <200003120759.CAA24402@indy.delorie.com> <200003151624.LAA01228@indy.delorie.com> <38D7F31D.1827@cygnus.com> <200003220930.EAA13024@indy.delorie.com>
X-SW-Source: 2000-03/msg00468.html
Content-length: 2019

Eli Zaretskii wrote:

> (I did look in the manual, but since the snippet you cited isn't
> indexed, I didn't find it.  [Yes, I will submit a manual change to add
> an index entry.])

http://sourceware.cygnus.com/gdb/onlinedocs/gdb_6.html#SEC34
four or five paragraphs down.

> To me, the fact that the test suite tried to do this was a sign that
> it was supposed to work.

Not a very reliable guide, I'm afraid.  That test was added in
1995, but as far as I know it did not work even then.  Perhaps
no one knew that it didn't.

> As an aside: is there any place I can find the list of tests which
> fail, and on what systems do they fail?

I'm afraid not.  Such a list would change daily.

> > If you seriously want to undertake this project, we can
> > work on a list of criteria that should be tested (things
> > that can go wrong).
> 
> I will put it on my todo (thanks for the list of things to test; 

Remember it was just a partial list off the top of my head.
I'm sure there are lots more issues to consider.

> > On top of that, I have grave concerns about being able
> > to correctly save and restore all of the internal
> > debugger state necessary to make this work (the
> > infrun execution state, the expression chain, etc.)
> 
> Err... I'm not sure this should be of concern here (but perhaps I
> don't see the subtle issues clearly enough): if the breakpoint
> commands change any of these global entities, I think the user expects
> the changes to be visible after these commands are processed.  For
> example, if the commands delete the breakpoint where you stopped, the
> user will expect the breakpoint to remain deleted after that (the
> changes I submitted do handle this specific case).  Am I missing
> something?

I'm not talking about anything user-visible -- I'm talking about
GDB's internal state.  All the variables with which it keeps 
track of what it's doing and what the child program is doing.
I don't have anything specific in mind, I just know there is
a lot to think about.

Michael
From dima@Chg.RU Wed Mar 22 11:48:00 2000
From: Dmitry Sivachenko <dima@Chg.RU>
To: gdb-patches@sourceware.cygnus.com
Subject: typo in gdb.texinfo
Date: Wed, 22 Mar 2000 11:48:00 -0000
Message-id: <200003221948.WAA31796@netserv1.chg.ru>
X-SW-Source: 2000-03/msg00469.html
Content-length: 1030

Please swap these two lines in the @menu.  This is how these chapters
actually appear in the manual.

Thank you in advance,
Dima.

--- gdb.1.4.texinfo	Wed Mar 22 22:45:32 2000
+++ gdb.1.4.texinfo.new	Wed Mar 22 22:44:43 2000
@@ -142,13 +142,13 @@
 * Controlling GDB::             Controlling @value{GDBN}
 * Sequences::                   Canned sequences of commands
 * Emacs::                       Using @value{GDBN} under @sc{gnu} Emacs
-* Annotations::                 @value{GDBN}'s annotations interface.
+* Annotations::                 @value{GDBN}'s annotations interface
 
 * GDB Bugs::                    Reporting bugs in @value{GDBN}
-* Formatting Documentation::    How to format and print @value{GDBN} documentation
 
 * Command Line Editing::        Command Line Editing
 * Using History Interactively:: Using History Interactively
+* Formatting Documentation::    How to format and print @value{GDBN} documentation
 * Installing GDB::              Installing GDB
 * Index::                       Index
 @end menu
From assign@gnu.org Wed Mar 22 12:14:00 2000
From: assignments <assign@gnu.org>
To: gdb-patches@sourceware.cygnus.com
Subject: GDB assigns/disclaims
Date: Wed, 22 Mar 2000 12:14:00 -0000
Message-id: <200003222013.PAA12928@delysid.gnu.org>
X-SW-Source: 2000-03/msg00470.html
Content-length: 1183

The following disclaimers and/or assignments concerning GDB
have recently been added to the file copyright.list here at the 
Free Software Foundation.  If you have any questions or corrections,
please send them to my general work address, 3diff@gnu.org.
                                     Thanks!
                                     Brian Youmans
                                     Assignments Clerk

GDB     David Whedon    US 1975 2000-02-25
Assigns past and future changes. (ser-tcp.c, command.[ch], top.c,
commands.exp, gdbint.texinfo)
dwhedon@gordian.com

GDB     Gordian 2000-03-01
Disclaims changes by David Whedon in the past and for one year.

GDB Andreas Jaeger      Germany 1969    2000-02-16
Assigns past and future changes.
aj@suse.de

GDB     Serge V. Vakulenko      Russia 1966     2000-01-31
Assigns past and future changes.  (patch for remote debugging of
Atmel AVR microcontrollers via the serial port)
vak@cronyx.ru

GDB     Techniche Universita:t Mu:nchen, Institute for Real-Time Computer Systems       2000-02-17
Disclaims changes by Gunter Magin and Linux BDM device driver by Michael Schraut
and Gunter Magin.
Georg.Faerber@rcs.ei.tum.de (Georg Fa:rber)
From msnyder@cygnus.com Wed Mar 22 12:41:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: Jim Blandy <jimb@cygnus.com>, hjl@lucon.org, gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Problems with hardware watchpoint on ia32.
Date: Wed, 22 Mar 2000 12:41:00 -0000
Message-id: <38D92F29.A3D@cygnus.com>
References: <20000307132401.A20282@valinux.com> <200003081008.FAA16481@indy.delorie.com> <20000308084304.A3150@lucon.org> <200003091210.HAA19857@indy.delorie.com> <npya7c6zn7.fsf@zwingli.cygnus.com> <200003221806.NAA14225@indy.delorie.com>
X-SW-Source: 2000-03/msg00471.html
Content-length: 759

Eli Zaretskii wrote:
> 
> > Eli's test of the value's type is incorrect if the watch expression
> > contains a structure comparison, like (foo == bar) || (something
> > else), where foo and bar are structures.  In that case, there will be
> > a value of type "struct", not at the end of the value list, but which
> > should be watched in its entirety.
> 
> Errr... do you have an actual example program where this happens?
> 
> I seem to be unable to reproduce the problem, at least in a C program:
> whenever I say "watch foo == bar" (where foo and bar are structs), GDB
> curses thusly:
> 
>         Structure has no component named operator==.

Argh... gdb does not seem to know that struct compare
is permitted.  I'll publish a patch.

				Michael Snyder
From msnyder@cygnus.com Wed Mar 22 12:43:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH]: Allow struct compare in expressions.
Date: Wed, 22 Mar 2000 12:43:00 -0000
Message-id: <200003222043.MAA10512@cleaver.cygnus.com>
X-SW-Source: 2000-03/msg00472.html
Content-length: 4627

The following change allows GDB to evaluate (and set watchpoints on)
expressions of the form (a == b) and (a != b), where a and b are
simple C structs or unions.  It would be possible to extend this
further by allowing simple binary comparison for classes that don't
have an operator== method: I leave that as an exercise for someone
else.

Jim Blandy, David Taylor, I think both of your approvals is required.

2000-03-22  Michael Snyder  <msnyder@cleaver.cygnus.com>

        * eval.c (evaluate_subexp_standard): allow for simple comparison
        of structures, in the absense of C++ method symbols.
        * symtab.c (total_number_of_methods): make public, for use above.
        * symtab.h (total_number_of_methods): publish prototype.

Index: ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/ChangeLog,v
retrieving revision 1.163
diff -c -r1.163 ChangeLog
*** ChangeLog	2000/03/22 09:45:01	1.163
--- ChangeLog	2000/03/22 20:38:33
***************
*** 1,3 ****
--- 1,10 ----
+ 2000-03-22  Michael Snyder  <msnyder@cleaver.cygnus.com>
+ 
+ 	* eval.c (evaluate_subexp_standard): allow for simple comparison
+ 	of structures, in the absense of C++ method symbols.
+ 	* symtab.c (total_number_of_methods): make public, for use above.
+ 	* symtab.h (total_number_of_methods): publish prototype.
+ 
  2000-03-22  Mark Kettenis  <kettenis@gnu.org>
  
  	* config/i386/tm-i386aix.h (I386_AIX_TARGET): Remove.
Index: eval.c
===================================================================
RCS file: /cvs/src/src/gdb/eval.c,v
retrieving revision 1.2
diff -c -r1.2 eval.c
*** eval.c	2000/03/14 17:01:04	1.2
--- eval.c	2000/03/22 20:38:34
***************
*** 1448,1454 ****
        arg2 = evaluate_subexp (VALUE_TYPE (arg1), exp, pos, noside);
        if (noside == EVAL_SKIP)
  	goto nosideret;
!       if (binop_user_defined_p (op, arg1, arg2))
  	{
  	  return value_x_binop (arg1, arg2, op, OP_NULL, noside);
  	}
--- 1448,1459 ----
        arg2 = evaluate_subexp (VALUE_TYPE (arg1), exp, pos, noside);
        if (noside == EVAL_SKIP)
  	goto nosideret;
! 
!       /* NOTE: because BINOP_EQUAL is a legal operaton for 
! 	 C structs (as opposed to C++ classes), revert to 
! 	 simple value comparison if the type has no methods.  */
!       if (binop_user_defined_p (op, arg1, arg2) &&
! 	  total_number_of_methods (arg1->type) > 0)
  	{
  	  return value_x_binop (arg1, arg2, op, OP_NULL, noside);
  	}
***************
*** 1463,1469 ****
        arg2 = evaluate_subexp (VALUE_TYPE (arg1), exp, pos, noside);
        if (noside == EVAL_SKIP)
  	goto nosideret;
!       if (binop_user_defined_p (op, arg1, arg2))
  	{
  	  return value_x_binop (arg1, arg2, op, OP_NULL, noside);
  	}
--- 1468,1479 ----
        arg2 = evaluate_subexp (VALUE_TYPE (arg1), exp, pos, noside);
        if (noside == EVAL_SKIP)
  	goto nosideret;
! 
!       /* NOTE: because BINOP_NOTEQUAL is a legal operaton for 
! 	 C structs (as opposed to C++ classes), revert to 
! 	 simple value comparison if the type has no methods.  */
!       if (binop_user_defined_p (op, arg1, arg2) &&
! 	  total_number_of_methods (arg1->type) > 0)
  	{
  	  return value_x_binop (arg1, arg2, op, OP_NULL, noside);
  	}
Index: symtab.c
===================================================================
RCS file: /cvs/src/src/gdb/symtab.c,v
retrieving revision 1.2
diff -c -r1.2 symtab.c
*** symtab.c	2000/02/08 04:39:02	1.2
--- symtab.c	2000/03/22 20:38:34
***************
*** 2217,2225 ****
     reader because the type of the baseclass might still be stubbed
     when the definition of the derived class is parsed.  */
  
! static int total_number_of_methods PARAMS ((struct type * type));
! 
! static int
  total_number_of_methods (type)
       struct type *type;
  {
--- 2217,2223 ----
     reader because the type of the baseclass might still be stubbed
     when the definition of the derived class is parsed.  */
  
! int
  total_number_of_methods (type)
       struct type *type;
  {
Index: symtab.h
===================================================================
RCS file: /cvs/src/src/gdb/symtab.h,v
retrieving revision 1.4
diff -c -r1.4 symtab.h
*** symtab.h	2000/03/21 22:37:42	1.4
--- symtab.h	2000/03/22 20:38:34
***************
*** 1462,1467 ****
--- 1462,1472 ----
  extern int
  in_prologue PARAMS ((CORE_ADDR pc, CORE_ADDR func_start));
  
+ /* Number of method symbols for TYPE
+    (and all its base classes) */
+ extern int 
+ total_number_of_methods PARAMS ((struct type * type));
+ 
  extern struct symbol *
    fixup_symbol_section PARAMS ((struct symbol *, struct objfile *));
  
From gkm@cygnus.com Wed Mar 22 12:45:00 2000
From: gkm@cygnus.com (glen mccready)
To: Elena Zannoni <ezannoni@cygnus.com>, gdb-patches@sourceware.cygnus.com
Cc: Fernando Nasser <fnasser@redhat.com>, Chris Faylor <cgf@cygnus.com>
Subject: sim/arm/wrapper.c fix.
Date: Wed, 22 Mar 2000 12:45:00 -0000
Message-id: <200003222045.MAA03959@cygint.cygnus.com>
X-SW-Source: 2000-03/msg00473.html
Content-length: 1457

Index: ChangeLog
===================================================================
RCS file: /cvs/cvsfiles/devo/sim/arm/ChangeLog,v
retrieving revision 1.77
diff -c -b -r1.77 ChangeLog
*** ChangeLog	1998/09/14 17:04:36	1.77
--- ChangeLog	2000/03/22 20:27:15
***************
*** 1,3 ****
--- 1,7 ----
+ Wed Mar 22 15:24:21 2000  glen mccready  <gkm@pobox.com>
+ 
+ 	* wrapper.c (sim_open,sim_close): Copy into myname, free myname
+ 
  Mon Sep 14 09:00:05 1998  Nick Clifton  <nickc@cygnus.com>
  
  	* wrapper.c (sim_open): Set endianness according to BFD or command
Index: wrapper.c
===================================================================
RCS file: /cvs/cvsfiles/devo/sim/arm/wrapper.c,v
retrieving revision 1.24
diff -c -b -r1.24 wrapper.c
*** wrapper.c	1998/09/14 17:04:36	1.24
--- wrapper.c	2000/03/22 20:27:15
***************
*** 347,353 ****
       char **argv;
  {
    sim_kind = kind;
!   myname = argv[0];
    sim_callback = ptr;
    
    /* Decide upon the endian-ness of the processor.
--- 347,354 ----
       char **argv;
  {
    sim_kind = kind;
!   if (myname) free(myname);
!   myname = xstrdup(argv[0]);
    sim_callback = ptr;
    
    /* Decide upon the endian-ness of the processor.
***************
*** 405,411 ****
       SIM_DESC sd;
       int quitting;
  {
!   /* nothing to do */
  }
  
  SIM_RC
--- 406,413 ----
       SIM_DESC sd;
       int quitting;
  {
!   if (myname) free(myname);
!   myname = 0;
  }
  
  SIM_RC
From Peter.Schauer@regent.e-technik.tu-muenchen.de Wed Mar 22 12:57:00 2000
From: "Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH] printcmd.c: Truncate output width of p/a and x/a if necessary
Date: Wed, 22 Mar 2000 12:57:00 -0000
Message-id: <200003222057.VAA24195@reisser.regent.e-technik.tu-muenchen.de>
X-SW-Source: 2000-03/msg00474.html
Content-length: 1272

FYI,

I checked in the attached patch. It gets rid of the
gdb.base/long_long.exp: x/a &oct
testsuite failure on Solaris 2.7 sparc. For more information see

http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00555.html


2000-03-22  Peter Schauer  <pes@regent.e-technik.tu-muenchen.de>

	* printcmd.c (print_scalar_formatted):  Truncate addresses to the
	size of a target pointer before passing them to print_address.


Index: printcmd.c
===================================================================
RCS file: /cvs/src/src/gdb/printcmd.c,v
retrieving revision 1.1.1.8
diff -u -p -r1.1.1.8 printcmd.c
--- printcmd.c	2000/02/05 07:29:47	1.1.1.8
+++ printcmd.c	2000/03/22 20:48:31
@@ -443,7 +443,14 @@ print_scalar_formatted (valaddr, type, f
       break;
 
     case 'a':
-      print_address (unpack_pointer (type, valaddr), stream);
+      {
+	/* Truncate address to the size of a target pointer, avoiding
+	   shifts larger or equal than the width of a CORE_ADDR.  */
+	CORE_ADDR addr = unpack_pointer (type, valaddr);
+	if (TARGET_PTR_BIT < (sizeof (CORE_ADDR) * HOST_CHAR_BIT))
+	  addr &= ((CORE_ADDR) 1 << TARGET_PTR_BIT) - 1;
+	print_address (addr, stream);
+      }
       break;
 
     case 'c':

-- 
Peter Schauer			pes@regent.e-technik.tu-muenchen.de
From taylor@cygnus.com Wed Mar 22 12:58:00 2000
From: David Taylor <taylor@cygnus.com>
To: Michael Snyder <msnyder@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH]: Allow struct compare in expressions.
Date: Wed, 22 Mar 2000 12:58:00 -0000
Message-id: <200003222057.PAA23063@texas.cygnus.com>
X-SW-Source: 2000-03/msg00476.html
Content-length: 5148

    From: Michael Snyder <msnyder@cygnus.com>
    Date: Wed, 22 Mar 2000 12:43:56 -0800 (PST)

    The following change allows GDB to evaluate (and set watchpoints on)
    expressions of the form (a == b) and (a != b), where a and b are
    simple C structs or unions.  It would be possible to extend this
    further by allowing simple binary comparison for classes that don't
    have an operator== method: I leave that as an exercise for someone
    else.

    Jim Blandy, David Taylor, I think both of your approvals is required.

    2000-03-22  Michael Snyder  <msnyder@cleaver.cygnus.com>

	    * eval.c (evaluate_subexp_standard): allow for simple comparison
	    of structures, in the absense of C++ method symbols.
	    * symtab.c (total_number_of_methods): make public, for use above.
	    * symtab.h (total_number_of_methods): publish prototype.

Approved.

    Index: ChangeLog
    ===================================================================
    RCS file: /cvs/src/src/gdb/ChangeLog,v
    retrieving revision 1.163
    diff -c -r1.163 ChangeLog
    *** ChangeLog   2000/03/22 09:45:01     1.163
    --- ChangeLog   2000/03/22 20:38:33
    ***************
    *** 1,3 ****
    --- 1,10 ----
    + 2000-03-22  Michael Snyder  <msnyder@cleaver.cygnus.com>
    + 
    +       * eval.c (evaluate_subexp_standard): allow for simple comparison
    +       of structures, in the absense of C++ method symbols.
    +       * symtab.c (total_number_of_methods): make public, for use above.
    +       * symtab.h (total_number_of_methods): publish prototype.
    + 
      2000-03-22  Mark Kettenis  <kettenis@gnu.org>

	    * config/i386/tm-i386aix.h (I386_AIX_TARGET): Remove.
    Index: eval.c
    ===================================================================
    RCS file: /cvs/src/src/gdb/eval.c,v
    retrieving revision 1.2
    diff -c -r1.2 eval.c
    *** eval.c      2000/03/14 17:01:04     1.2
    --- eval.c      2000/03/22 20:38:34
    ***************
    *** 1448,1454 ****
	    arg2 = evaluate_subexp (VALUE_TYPE (arg1), exp, pos, noside);
	    if (noside == EVAL_SKIP)
	    goto nosideret;
    !       if (binop_user_defined_p (op, arg1, arg2))
	    {
	      return value_x_binop (arg1, arg2, op, OP_NULL, noside);
	    }
    --- 1448,1459 ----
	    arg2 = evaluate_subexp (VALUE_TYPE (arg1), exp, pos, noside);
	    if (noside == EVAL_SKIP)
	    goto nosideret;
    ! 
    !       /* NOTE: because BINOP_EQUAL is a legal operaton for 
    !        C structs (as opposed to C++ classes), revert to 
    !        simple value comparison if the type has no methods.  */
    !       if (binop_user_defined_p (op, arg1, arg2) &&
    !         total_number_of_methods (arg1->type) > 0)
	    {
	      return value_x_binop (arg1, arg2, op, OP_NULL, noside);
	    }
    ***************
    *** 1463,1469 ****
	    arg2 = evaluate_subexp (VALUE_TYPE (arg1), exp, pos, noside);
	    if (noside == EVAL_SKIP)
	    goto nosideret;
    !       if (binop_user_defined_p (op, arg1, arg2))
	    {
	      return value_x_binop (arg1, arg2, op, OP_NULL, noside);
	    }
    --- 1468,1479 ----
	    arg2 = evaluate_subexp (VALUE_TYPE (arg1), exp, pos, noside);
	    if (noside == EVAL_SKIP)
	    goto nosideret;
    ! 
    !       /* NOTE: because BINOP_NOTEQUAL is a legal operaton for 
    !        C structs (as opposed to C++ classes), revert to 
    !        simple value comparison if the type has no methods.  */
    !       if (binop_user_defined_p (op, arg1, arg2) &&
    !         total_number_of_methods (arg1->type) > 0)
	    {
	      return value_x_binop (arg1, arg2, op, OP_NULL, noside);
	    }
    Index: symtab.c
    ===================================================================
    RCS file: /cvs/src/src/gdb/symtab.c,v
    retrieving revision 1.2
    diff -c -r1.2 symtab.c
    *** symtab.c    2000/02/08 04:39:02     1.2
    --- symtab.c    2000/03/22 20:38:34
    ***************
    *** 2217,2225 ****
	 reader because the type of the baseclass might still be stubbed
	 when the definition of the derived class is parsed.  */

    ! static int total_number_of_methods PARAMS ((struct type * type));
    ! 
    ! static int
      total_number_of_methods (type)
	   struct type *type;
      {
    --- 2217,2223 ----
	 reader because the type of the baseclass might still be stubbed
	 when the definition of the derived class is parsed.  */

    ! int
      total_number_of_methods (type)
	   struct type *type;
      {
    Index: symtab.h
    ===================================================================
    RCS file: /cvs/src/src/gdb/symtab.h,v
    retrieving revision 1.4
    diff -c -r1.4 symtab.h
    *** symtab.h    2000/03/21 22:37:42     1.4
    --- symtab.h    2000/03/22 20:38:34
    ***************
    *** 1462,1467 ****
    --- 1462,1472 ----
      extern int
      in_prologue PARAMS ((CORE_ADDR pc, CORE_ADDR func_start));

    + /* Number of method symbols for TYPE
    +    (and all its base classes) */
    + extern int 
    + total_number_of_methods PARAMS ((struct type * type));
    + 
      extern struct symbol *
	fixup_symbol_section PARAMS ((struct symbol *, struct objfile *));