Re: Hardware watchpoints

[Jim Blandy <jimb@cygnus.com>]

> Thanks for the explanations.

(I hope I wasn't explaining stuff you already knew!! :) )

> An abridged script of a GDB session follows.  As you see, I watched
> two different members of a struct variable `foo_var': `foo_var.iv' and
> `foo_var.jv'.  GDB produced two value chains, each one including the
> struct member and the struct itself--all of them marked as lazy.

Ahh!  I think I know the problem.

> Perhaps we could use v->type.code in the decision whether to watch any
> values but the first one on the value chain?

I don't think that's quite right.

> One question that I still can't figure out is why does GDB at all
> _need_ to have the parent struct on the value chain?  Where is that
> information used?

GDB doesn't *need* it, per se.  It's just that, as evaluate_expression
runs, as it walks the expression, each operator, variable, constant,
etc. produces a struct value, holding the value of that subexpression.
I think, before watchpoints were implemented, the only reason GDB ever
chained them together was so it could free them before reading the
next user command.  Whoever implemented watchpoints noticed that the
value chain also happened to form a list of the objects touched by an
expression, and thus a list of things which might need to be watched.

The problem is that nobody ever uses the value returned by the call to
evaluate_expression in insert_breakpoints, so it remains lazy.  Try
this, in addition to my previous change:

*** breakpoint.c	1999/10/21 19:16:52	1.254
--- breakpoint.c	1999/10/24 19:21:53
***************
*** 851,856 ****
--- 851,858 ----
  	    /* Evaluate the expression and cut the chain of values
  	       produced off from the value chain.  */
  	    v = evaluate_expression (b->exp);
+ 	    if (VALUE_LAZY (v))
+ 	      value_fetch_lazy (v);
  	    value_release_to_mark (mark);
  
  	    b->val_chain = v;
From ac131313@cygnus.com Sun Oct 24 17:53:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: richard.earnshaw@arm.com
Cc: Grant Edwards <grante@visi.com>, "J.T. Conklin" <jtc@redback.com>, Grant.Edwards@comtrol.com, gdb@sourceware.cygnus.com
Subject: Re: wrong htons() used?
Date: Sun, 24 Oct 1999 17:53:00 -0000
Message-id: <3813A9AC.D896D4BD@cygnus.com>
References: <199910221526.QAA16254@cam-mail1.cambridge.arm.com>
X-SW-Source: 1999-q4/msg00152.html
Content-length: 655

Richard Earnshaw wrote:
> 
> > I thing the best option is to rename rdi-share/endian.h so that it
> > doesn't shadow /usr/include/endian.h.  rdi-share/endian.h doesn't
> > appeart to be some strictly local stuff and not intented as a
> > replacement for /usr/include/endian.h.
> 
> And maybe while they are fixing it they can track down and shoot the glibc
> person who put another non-standard header in a standard place...

Unfortunatly you would have to go back a long way. Endian.h has a (C)
date of 1992.

More seriously, why is <netinet/in.h> picking up the wrong endian.h? 
Has this always happened or has something else recently changed?

	Andrew
From ac131313@cygnus.com Sun Oct 24 18:21:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: async event loop and ^C
Date: Sun, 24 Oct 1999 18:21:00 -0000
Message-id: <3813B055.5C62C3C7@cygnus.com>
References: <5mzoxbl03y.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q4/msg00153.html
Content-length: 538

"J.T. Conklin" wrote:
> 
> What is the recommended way to handle this?  I see that remote.c
> installs a new SIGINT handler while waiting for execution.  I can do
> the same, but it doesn't seem right.
> 

FYI,

That's very old code being given a tempoary makeover.  It isn't right
(it is better than it was though - at least remote.c now provides
terminal_ours/terminal_inferior).  The implementation of the double
cntrl-c mechanism is eventually being moved out of remote.c.  Remote.c
would only see the call to target_stop().

	Andrew
From grante@visi.com Sun Oct 24 18:31:00 1999
From: Grant Edwards <grante@visi.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: richard.earnshaw@arm.com, "J.T. Conklin" <jtc@redback.com>, Grant.Edwards@comtrol.com, gdb@sourceware.cygnus.com
Subject: Re: wrong htons() used?
Date: Sun, 24 Oct 1999 18:31:00 -0000
Message-id: <19991024203029.A3662@visi.com>
References: <199910221526.QAA16254@cam-mail1.cambridge.arm.com> <3813A9AC.D896D4BD@cygnus.com>
X-SW-Source: 1999-q4/msg00154.html
Content-length: 1001

On Mon, Oct 25, 1999 at 10:51:56AM +1000, Andrew Cagney wrote:
>
> > > I thing the best option is to rename rdi-share/endian.h so that it
> > > doesn't shadow /usr/include/endian.h.  rdi-share/endian.h doesn't
> > > appeart to be some strictly local stuff and not intented as a
> > > replacement for /usr/include/endian.h.
> > 
> > And maybe while they are fixing it they can track down and shoot the glibc
> > person who put another non-standard header in a standard place...
> 
> Unfortunatly you would have to go back a long way. Endian.h has a (C)
> date of 1992.
> 
> More seriously, why is <netinet/in.h> picking up the wrong endian.h? 
> Has this always happened or has something else recently changed?

It seems that it's been this way for quite a while.  The e-mail I got
from the JTAG interface box vendor said that in the past, people just
changed the #define for the port number so that it worked.

Apparently there was only one spot where it mattered.

-- 
Grant Edwards
grante@visi.com