Hardware Watchpoints

Hardware Watchpoints

[Steven Johnson]

Does anyone know if hardware watchpoints are supposed to work with the 
GDB standard remote protocol.  They are documented in the protocol (Z 
packets), and there even appears to be code in remote.c, but there seems 
to be no way to activate them.  What am I missing?

Yes, i tried "set remote Z-packet on" which seems to do not much useful.

Im using a very late snapshot just prior GDB 5.3, I don't recall seeing 
anything about this in the GDB 5.3 release notes.

Steven Johnson

Re: Hardware Watchpoints

[Andrew Cagney]

> Does anyone know if hardware watchpoints are supposed to work with the GDB standard remote protocol.  They are documented in the protocol (Z packets), and there even appears to be code in remote.c, but there seems to be no way to activate them.  What am I missing?
> 
> Yes, i tried "set remote Z-packet on" which seems to do not much useful.
> 
> Im using a very late snapshot just prior GDB 5.3, I don't recall seeing anything about this in the GDB 5.3 release notes.

They, er, almost work.  I found a problem when testing them just before 
taking my summer break.  Need to get the patch integrated.

Briefly, GDB thinks that the target supports zero hardware breakpoints 
and there is no way (minus editing a file) of changing this.

Andrew

Re: Hardware watchpoints

[Eli Zaretskii]

As promised, diffs for all the changes that avoid inserting/removing
watchpoints for lazy values are attached below.

Now for the next problem: hardware watchpoints still don't work, even
after these changes, for struct members that are bitfields.  As far as
I could see, the reason for this is that value_primitive_field needs
to fetch the value of the field in order to unpack it into an int, and
that causes the lazy flag of the struct itself to be reset.

It seems that relying on the lazy flag is too fragile: any code that
needs to fetch the value of the struct, for some purpose, will break
the ability to watch members of that struct.

Perhaps we need a special flag for this, which will be set for structs
and arrays only if they are not the watched expression itself.


	* breakpoint.c (insert_breakpoints): Fetch the value of the
	expression we need to watch, to make sure its LAZY flag is off.
	Don't insert watchpoints for values whose LAZY flag is set.
	(remove_breakpoint): Don't remove a watchpoint if the value's LAZY
	flag is set (since we didn't insert them in the first place).
	(bpstat_stop_status): Don't check values whose LAZY flag is set,
	since we don't watch them.


*** gdb/breakpoi.c~4	Sun Aug 22 19:03:14 1999
--- gdb/breakpoi.c	Wed Oct 27 19:37:04 1999
*************** insert_breakpoints ()
*** 779,784 ****
--- 779,786 ----
  	      /* 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;
*************** insert_breakpoints ()
*** 788,794 ****
  	      for ( ; v; v=v->next)
  		{
  		  /* If it's a memory location, then we must watch it.  */
! 		  if (v->lval == lval_memory)
  		    {
  		      int addr, len, type;
  		    
--- 790,796 ----
  	      for ( ; v; v=v->next)
  		{
  		  /* If it's a memory location, then we must watch it.  */
! 		  if (v->lval == lval_memory && !v->lazy)
  		    {
  		      int addr, len, type;
  		    
*************** remove_breakpoint (b, is)
*** 1127,1133 ****
  	{
  	  /* For each memory reference remove the watchpoint
  	     at that address.  */
! 	  if (v->lval == lval_memory)
  	    {
  	      int addr, len, type;
  	      
--- 1129,1135 ----
  	{
  	  /* For each memory reference remove the watchpoint
  	     at that address.  */
! 	  if (v->lval == lval_memory && !v->lazy)
  	    {
  	      int addr, len, type;
  	      
*************** bpstat_stop_status (pc, not_a_breakpoint
*** 2199,2205 ****
  	    }
            for (v = b->val_chain; v; v = v->next)
              {
!               if (v->lval == lval_memory)
                  {
                    CORE_ADDR vaddr;
  
--- 2201,2207 ----
  	    }
            for (v = b->val_chain; v; v = v->next)
              {
!               if (v->lval == lval_memory && !v->lazy)
                  {
                    CORE_ADDR vaddr;
  
*************** can_use_hardware_watchpoint (v)
*** 4486,4492 ****
       hardware watchpoint for the constant expression.  */
    for ( ; v; v = v->next)
      {
!       if (v->lval == lval_memory)
  	{
  	  int vaddr = VALUE_ADDRESS (v) + VALUE_OFFSET (v);
  	  int len = TYPE_LENGTH (VALUE_TYPE (v));
--- 4488,4494 ----
       hardware watchpoint for the constant expression.  */
    for ( ; v; v = v->next)
      {
!       if (v->lval == lval_memory && !v->lazy)
  	{
  	  int vaddr = VALUE_ADDRESS (v) + VALUE_OFFSET (v);
  	  int len = TYPE_LENGTH (VALUE_TYPE (v));
From hjl@valinux.com Wed Oct 27 13:43:00 1999
From: hjl@valinux.com (H.J. Lu)
To: gdb-patches@sourceware.cygnus.com
Cc: slouken@devolution.com, gdb@sourceware.cygnus.com (GDB)
Subject: A patch for shared library support
Date: Wed, 27 Oct 1999 13:43:00 -0000
Message-id: <19991027204300.7816E3FC1@valinux.com>
X-SW-Source: 1999-q4/msg00175.html
Content-length: 3401

Hi,

I finally get annoyed enough to port Sam's patch to gdb 4.18 in CVS.
When you set a break point in shared library, gdb will crash when you
restart the program. This patch seems to work for me.


-- 
H.J. Lu (hjl@gnu.org)
--
Wed Mar 17 19:49:22 1999  Sam Lantinga (slouken@devolution.com)

	Added function check_solib_consistency() to reload list of
	shared objects when they are added or deleted. This fixed
	crashing when the program being debugged unloaded a dynamic
	library and added a new library afterwards.

	* solib.h (CHECK_SOLIB_CONSISTENCY): New.
	(check_solib_consistency): New prototype.

	* solib.c (check_solib_consistency): Defined.

	* infrun.c (handle_inferior_event): Before calling SOLIB_ADD (),
	call CHECK_SOLIB_CONSISTENCY () if defined.

Index: solib.h
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/solib.h,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 solib.h
--- solib.h	1999/09/09 00:38:38	1.1.1.1
+++ solib.h	1999/10/27 20:35:54
@@ -186,6 +186,11 @@ solib_create_inferior_hook PARAMS ((void
 extern char *
   solib_address PARAMS ((CORE_ADDR));	/* solib.c */
 
+/* Check shared library consistency */
+
+#define CHECK_SOLIB_CONSISTENCY()	check_solib_consistency()
+extern void check_solib_consistency PARAMS ((void));
+
 /* If ADDR lies in a shared library, return its name.  */
 
 #define PC_SOLIB(addr)	solib_address (addr)
Index: solib.c
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/solib.c,v
retrieving revision 1.1.1.2
diff -u -p -r1.1.1.2 solib.c
--- solib.c	1999/10/19 16:16:27	1.1.1.2
+++ solib.c	1999/10/27 20:29:03
@@ -950,6 +954,38 @@ open_symbol_file_object (arg)
   return 1;
 }
 #endif /* SVR4_SHARED_LIBS */
+
+/*
+  
+GLOBAL FUNCTION
+
+	check_solib_consistency -- check solib list consistency
+
+SYNOPSIS
+
+	void check_solib_consistency (void)
+
+DESCRIPTION
+
+	This module is called whenever we hit a dynamic linker breakpoint
+	and allows us to check the consistency of our shared object list.
+	Without this, dynamic unlinking of objects could crash us.
+ */
+
+void
+check_solib_consistency (void)
+{
+#ifdef SVR4_SHARED_LIBS
+
+  if ( debug_base ) {
+    read_memory (debug_base, (char *) &debug_copy, sizeof (struct r_debug));
+    /* If the shared object state is consistent, we can reload our list */
+    if ( debug_copy.r_state == RT_CONSISTENT )
+      clear_solib();
+  }
+
+#endif	/* SVR4_SHARED_LIBS */
+}
 
 /*
 
Index: infrun.c
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/infrun.c,v
retrieving revision 1.1.1.2
diff -u -p -r1.1.1.2 infrun.c
--- infrun.c	1999/10/19 16:16:22	1.1.1.2
+++ infrun.c	1999/10/27 20:30:20
@@ -1479,6 +1479,9 @@ handle_inferior_event (struct execution_
 		/* Switch terminal for any messages produced by
 		   breakpoint_re_set.  */
 		target_terminal_ours_for_output ();
+#ifdef CHECK_SOLIB_CONSISTENCY
+		CHECK_SOLIB_CONSISTENCY();
+#endif
 		SOLIB_ADD (NULL, 0, NULL);
 		target_terminal_inferior ();
 	      }
@@ -2409,6 +2412,9 @@ handle_inferior_event (struct execution_
 		/* Switch terminal for any messages produced by
 		   breakpoint_re_set.  */
 		target_terminal_ours_for_output ();
+#ifdef CHECK_SOLIB_CONSISTENCY
+		CHECK_SOLIB_CONSISTENCY();
+#endif
 		SOLIB_ADD (NULL, 0, NULL);
 		target_terminal_inferior ();
 	      }
From jimb@cygnus.com Wed Oct 27 23:44:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Hardware watchpoints
Date: Wed, 27 Oct 1999 23:44:00 -0000
Message-id: <npk8o8m1ch.fsf@zwingli.cygnus.com>
References: <np3dv6k64w.fsf@zwingli.cygnus.com> <19991019235249.917DC1B494@ocean.lucon.org> <199910201401.KAA28719@mescaline.gnu.org> <npvh82htxn.fsf@zwingli.cygnus.com> <199910221200.IAA24556@mescaline.gnu.org> <npn1tbnr5f.fsf@zwingli.cygnus.com> <199910231048.GAA31392@mescaline.gnu.org> <npaep8o97e.fsf@zwingli.cygnus.com> <npu2ndmzyh.fsf@zwingli.cygnus.com> <199910272007.QAA04553@mescaline.gnu.org>
X-SW-Source: 1999-q4/msg00176.html
Content-length: 1309

> Now for the next problem: hardware watchpoints still don't work, even
> after these changes, for struct members that are bitfields.  As far as
> I could see, the reason for this is that value_primitive_field needs
> to fetch the value of the field in order to unpack it into an int, and
> that causes the lazy flag of the struct itself to be reset.
> 
> It seems that relying on the lazy flag is too fragile: any code that
> needs to fetch the value of the struct, for some purpose, will break
> the ability to watch members of that struct.
> 
> Perhaps we need a special flag for this, which will be set for structs
> and arrays only if they are not the watched expression itself.

I agree that using the value chain is fragile.  It's my impression
that it was never intended for anything more than freeing old values.
Nobody ever promised that it would have any specific semantics.

Instead of adding yet another special flag, we could change
value_primitive_field, or whoever extracts bitfields, to create a new
value object, also on the chain, containing just the words from the
original value that hold the bitfield, and then let that smaller value
become unlazy.  That should yield exactly the words we need to set
hardware watchpoints on.

I'm not sure what type that intermediate value should have.
From aj@suse.de Thu Oct 28 01:31:00 1999
From: Andreas Jaeger <aj@suse.de>
To: gdb@sourceware.cygnus.com
Subject: Patch for warning in gdb/linux-thread.c
Date: Thu, 28 Oct 1999 01:31:00 -0000
Message-id: <u8ogdjx4xt.fsf@gromit.rhein-neckar.de>
X-SW-Source: 1999-q4/msg00177.html
Content-length: 5354

The current cvs version of gdb produces a number of harmless warnings
in linuxthreads.  I've fixed the following warnings with the appended
patch.

../../cvs/gdb/gdb/linux-thread.c:165: warning: missing initializer
../../cvs/gdb/gdb/linux-thread.c:165: warning: (near initialization for `linuxthreads_sig_restart.print')
../../cvs/gdb/gdb/linux-thread.c:168: warning: missing initializer
../../cvs/gdb/gdb/linux-thread.c:168: warning: (near initialization for `linuxthreads_sig_cancel.print')
../../cvs/gdb/gdb/linux-thread.c:171: warning: missing initializer
../../cvs/gdb/gdb/linux-thread.c:171: warning: (near initialization for `linuxthreads_sig_debug.print')
../../cvs/gdb/gdb/linux-thread.c: In function `linuxthreads_find_trap':
../../cvs/gdb/gdb/linux-thread.c:338: warning: suggest explicit braces to avoid ambiguous `else'
../../cvs/gdb/gdb/linux-thread.c: In function `resume_thread':
../../cvs/gdb/gdb/linux-thread.c:653: warning: suggest explicit braces to avoid ambiguous `else'
../../cvs/gdb/gdb/linux-thread.c: In function `stop_thread':
../../cvs/gdb/gdb/linux-thread.c:681: warning: suggest explicit braces to avoid ambiguous `else'
../../cvs/gdb/gdb/linux-thread.c: In function `linuxthreads_wait':
../../cvs/gdb/gdb/linux-thread.c:1286: warning: suggest explicit braces to avoid ambiguous `else'
../../cvs/gdb/gdb/linux-thread.c:1366: warning: suggest explicit braces to avoid ambiguous `else'

Andreas

1999-10-28  Andreas Jaeger  <aj@suse.de>

	* linux-thread.c: Add missing initializers to avoid gcc warnings.
	(resume_thread): Add braces as  recommended by gcc -Wparentheses.
	(stop_thread): Likewise.
	(linuxthreads_wait): Likewise.
	(linuxthreads_find_trap): Likewise.

--- gdb/linux-thread.c.~1~	Thu Sep  9 01:59:18 1999
+++ gdb/linux-thread.c	Thu Oct 28 10:28:53 1999
@@ -161,13 +161,13 @@ struct linuxthreads_signal {
 };
 
 struct linuxthreads_signal linuxthreads_sig_restart = {
-  "__pthread_sig_restart", 1, 0, 0, 0
+  "__pthread_sig_restart", 1, 0, 0, 0, 0
 };
 struct linuxthreads_signal linuxthreads_sig_cancel = {
-  "__pthread_sig_cancel", 1, 0, 0, 0
+  "__pthread_sig_cancel", 1, 0, 0, 0, 0
 };
 struct linuxthreads_signal linuxthreads_sig_debug = {
-  "__pthread_sig_debug", 0, 0, 0, 0
+  "__pthread_sig_debug", 0, 0, 0, 0, 0
 };
 
 /* A table of breakpoint locations, one per PID.  */
@@ -336,10 +336,12 @@ linuxthreads_find_trap (pid, stop)
       else if (WSTOPSIG(status) != SIGSTOP)
 	wstatus[last++] = status;
       else if (stop)
-	if (found_trap)
-	  break;
-	else
-	  found_stop = 1;
+	{
+	  if (found_trap)
+	    break;
+	  else
+	    found_stop = 1;
+	}
     }
 
   /* Resend any other signals we noticed to the thread, to be received
@@ -651,10 +653,12 @@ resume_thread (pid)
   if (pid != inferior_pid
       && in_thread_list (pid)
       && linuxthreads_thread_alive (pid))
-    if (pid == linuxthreads_step_pid)
-      child_resume (pid, 1, linuxthreads_step_signo);
-    else
-      child_resume (pid, 0, TARGET_SIGNAL_0);
+    {
+      if (pid == linuxthreads_step_pid)
+	child_resume (pid, 1, linuxthreads_step_signo);
+      else
+	child_resume (pid, 0, TARGET_SIGNAL_0);
+    }
 }
 
 /* Detach a thread */
@@ -679,21 +683,23 @@ stop_thread (pid)
     int pid;
 {
   if (pid != inferior_pid)
-    if (in_thread_list (pid))
-      kill (pid, SIGSTOP);
-    else if (ptrace (PT_ATTACH, pid, (PTRACE_ARG3_TYPE) 0, 0) == 0)
-      {
-	if (!linuxthreads_attach_pending)
-	  printf_unfiltered ("[New %s]\n", target_pid_to_str (pid));
-	add_thread (pid);
-	if (linuxthreads_sig_debug.signal)
-	  /* After a new thread in glibc 2.1 signals gdb its existence,
-	     it suspends itself and wait for linuxthreads_sig_restart,
-	     now we can wake up it. */
-	  kill (pid, linuxthreads_sig_restart.signal);
-      }
-    else
-      perror_with_name ("ptrace in stop_thread");
+    {
+      if (in_thread_list (pid))
+	kill (pid, SIGSTOP);
+      else if (ptrace (PT_ATTACH, pid, (PTRACE_ARG3_TYPE) 0, 0) == 0)
+	{
+	  if (!linuxthreads_attach_pending)
+	    printf_unfiltered ("[New %s]\n", target_pid_to_str (pid));
+	  add_thread (pid);
+	  if (linuxthreads_sig_debug.signal)
+	    /* After a new thread in glibc 2.1 signals gdb its existence,
+	       it suspends itself and wait for linuxthreads_sig_restart,
+	       now we can wake up it. */
+	    kill (pid, linuxthreads_sig_restart.signal);
+	}
+      else
+	perror_with_name ("ptrace in stop_thread");
+    }
 }
 
 /* Wait for a thread */
@@ -1284,10 +1290,12 @@ linuxthreads_wait (pid, ourstatus)
 	      if (rpid > 0)
 		break;
 	      if (rpid < 0)
-		if (errno == EINTR)
-		  continue;
-		else if (save_errno != 0)
-		  break;
+		{
+		  if (errno == EINTR)
+		    continue;
+		  else if (save_errno != 0)
+		    break;
+		}
 
 	      sigsuspend(&omask);
 	    }
@@ -1364,10 +1372,12 @@ linuxthreads_wait (pid, ourstatus)
 	    {
 	      /* Skip SIGSTOP signals.  */
 	      if (!linuxthreads_pending_status (rpid))
-		if (linuxthreads_step_pid == rpid)
-		  child_resume (rpid, 1, linuxthreads_step_signo);
-		else
-		  child_resume (rpid, 0, TARGET_SIGNAL_0);
+		{
+		  if (linuxthreads_step_pid == rpid)
+		    child_resume (rpid, 1, linuxthreads_step_signo);
+		  else
+		    child_resume (rpid, 0, TARGET_SIGNAL_0);
+		}
 	      continue;
 	    }
 

-- 
 Andreas Jaeger   
  SuSE Labs aj@suse.de	
   private aj@arthur.rhein-neckar.de
From bryce@albatross.co.nz Thu Oct 28 03:05:00 1999
From: Bryce McKinlay <bryce@albatross.co.nz>
To: "H.J. Lu" <hjl@valinux.com>
Cc: slouken@devolution.com, GDB <gdb@sourceware.cygnus.com>
Subject: Re: A patch for shared library support
Date: Thu, 28 Oct 1999 03:05:00 -0000
Message-id: <3818203B.28D094A5@albatross.co.nz>
References: <19991027204300.7816E3FC1@valinux.com>
X-SW-Source: 1999-q4/msg00178.html
Content-length: 393

Great! Thanks - this bug has been annoying me too, and the patch seems to have
fixed it. I've noticed that Redhat 6.1's gdb suffers from this as well.

regards

  [ bryce ]


"H.J. Lu" wrote:

> I finally get annoyed enough to port Sam's patch to gdb 4.18 in CVS.
> When you set a break point in shared library, gdb will crash when you
> restart the program. This patch seems to work for me.

Re: Hardware watchpoints

[Jim Blandy]

> > 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.

Sorry --- there's a better answer to that question.

In evaluating the expression x.y, the value chain will contain a value
for the entire structure x, and a value for the member, x.y.  The
former value is needed by the '.' operator; the operator extracts the
'y' member from it.
From toddpw@windriver.com Sun Oct 24 22:10:00 1999
From: Todd Whitesel <toddpw@windriver.com>
To: ogoh@cise.ufl.edu (Okehee Goh)
Cc: gdb@sourceware.cygnus.com (GDB Developers)
Subject: Re: [GDB] Can I get some sample program using debugging stub?
Date: Sun, 24 Oct 1999 22:10:00 -0000
Message-id: <199910250510.WAA09745@alabama.wrs.com>
References: <000e01bf1dd6$3b355120$8daae380@oriole.hsi-lab.cise.ufl.edu>
X-SW-Source: 1999-q4/msg00158.html
Content-length: 1333

> According to GDB manual, they said , "Insert set_debug_traps, breakpoint
> near the top of your program". But It's not concrete to me.

Pick a function like 'main' or 'myApp' or whatever you call your functions
that begin the program; and set a breakpoint there:

(gdb) break main

> I compiled GDB for "--target=sparc-wrs-vxworks" as target and solraris2 as

If you are using a public version of GDB, then this requires an older vxworks
target that supports 'RDB'. Newer targets (those shipped with Tornado 2.0) do
not support RDB any more.

I am working to get something appropriate for T2.0 into the public GDB but it
is slow going as I missed my best window of opportunity last winter by getting
really sick at just the wrong time.

> When tried to debug the application compiled under solaris2, it failed to
> read the file format. I guess the gdb which is made for cross debugging for
> another architecture can't work for the application of host that GDB works.
> Am I right?

That is generally true. If you build a program with gcc for a --target, then
you will also need a gdb for the same --target in order to debug it. If you
want to debug programs compiled by the solaris2 compiler, you should use a gdb
for --target=sparc-sun-solaris2.5.1 (or whatever version of solaris you have).

-- 
Todd Whitesel
toddpw @ wrs.com
From rearnsha@arm.com Mon Oct 25 03:26:00 1999
From: Richard Earnshaw <rearnsha@arm.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: richard.earnshaw@arm.com
Subject: Re: wrong htons() used? 
Date: Mon, 25 Oct 1999 03:26:00 -0000
Message-id: <199910251026.LAA20361@cam-mail1.cambridge.arm.com>
References: <3813A9AC.D896D4BD@cygnus.com>
X-SW-Source: 1999-q4/msg00159.html
Content-length: 470

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

Probably because it goes 

#include <endian.h> 

and is then compiled with a -I somewhere_with_a_different_endian.h

If I understand gcc's include searching rules properly, netinet/in.h 
should probably go

#include "../endian.h"

so that it will start the search will start from netinet rather than using 
the include path.

R.

Re: Hardware watchpoints

[Jim Blandy]

> 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

Re: Hardware watchpoints

[Eli Zaretskii]

> What expressions did you try to watch?  What chains of values did they
> produce?  Which ones are lazy, and which ones aren't?

Thanks for the explanations.

A simple test program is attached at the end of this message.  (It's a
program I used for testing several different aspects of watchpoints,
so not everything it includes is relevant to the issue at hand.)

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.

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

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?

Also, the v->type member for the parent struct has a NULL type.name
member.  Unless I misunderstood gdbtypes.h, it seems to imply that
name should be "struct" or "struct foo".

Here's the GDB session:

e:/src/gnu/gdb-4.18/gdb> gdb gdb.exe
...
(top-gdb) b breakpoint.c:781
Breakpoint 3 at 0x2c61: file breakpoint.c, line 781
(top-gdb) r fptest4
Starting program: e:/src/gnu/gdb-4.18/gdb/gdb.exe fptest4
...
(gdb) b main
Breakpoint 1 at 0x15bf: file fptest.c, line 7
(gdb) r
Starting program: e:/src/gnu/gdb-4.18/gdb/fptest4

Breakpoint 1, main (argv=1, argv=0x911c4) at fptest.c:7
7	  volatile double a = M_SQRT2;

(gdb) l 21,24
21	argc = a * a;
22	foo_var.iv = argc + 2;
23	foo_var.jv = argc + 3;
24	if (foo_var.iv < 0)
(gdb) watch foo_var.iv
Hardware watchpoint 2: foo_var.iv
(gdb) watch foo_var.jv
Hardware watchpoint 3: foo_var.jv
(gdb) c
Continuing.

Breakpoint 3, insert_breakpoints () at breakpoint.c:781
781		      v = evaluate_expression (b->exp);
(top-gdb) p b->exp_string
$1 = 0x1eabe8 "foo_var.iv"
(top-gdb) p *b->exp
$2 = {language_defn =
During symbol reading, stub type has NULL name.
0xc188, nelts = 9, elts = {{opcode = STRUCTOP_STRUCT, symbol = 0x56,
     ...}}}
(top-gdb) n
782		      value_release_to_mark (mark);
(top-gdb) p *v
$3 = {lval = lval_memory, modifiable = 1, location = {address = 0x90904,
    ...}, offset = 0, bitsize = 0, bitpos = 0, frame_addr = 0,
  type = 0x1e7710, enclosing_type = 0x1e7710, next = 0x1ea6f8,
  substring_addr = {memaddr = 0xea890, ...}, regno = -1, lazy = 1 '\001',
  optimized_out = 0 '\000', embedded_offset = 0, pointed_to_offset = 0,
  bfd_section = 0x0, aligner = {...}}
(top-gdb)p *(struct type *)v->type
$4 = {code = TYPE_CODE_INT, name = 0x1e7754 "int", tag_name = 0x0, length = 4,
    upper_bound_type = 0, lower_bound_type = 0, ..., cv_type = 0x1e7710,
  flags = 0, nfields = 0, fields = 0x0, ..., type_specific = {
    arg_types = 0x0, cplus_stuff = 0x0}}
(top-gdb)p *v->next
$5 = {lval = lval_memory, modifiable = 1, location = {address = 0x90904,
    ...}, offset = 0, bitsize = 0, bitpos = 0, frame_addr = 0,
  type = 0x1e7a3c, enclosing_type = 0x1e7a3c, next = 0x0,
  substring_addr = {memaddr = 0xea890, ...}, regno = -1, lazy = 1 '\001',
  optimized_out = 0 '\000', embedded_offset = 0, pointed_to_offset = 0,
  bfd_section = 0x0, aligner = {...}}
(top-gdb) p *(struct type *)v->next->type
$6 = {code = TYPE_CODE_STRUCT, name = 0x0, tag_name = 0x1ea390 "foo", 
    length = 20, upper_bound_type = 0, lower_bound_type = 0, ...,
  cv_type = 0x1e7a3c, flags = 0, nfields = 5, fields = 0x0x1e7ad4,
  vptr_basetype = 0x0, vptr_fieldno = -1, type_specific = {
    arg_types = 0x13c120, cplus_stuff = 0x13c120}}
(top-gdb) c
Continuing.

Breakpoint 3, insert_breakpoints () at breakpoint.c:781
781		      v = evaluate_expression (b->exp);
(top-gdb) p b->exp_string
$7 = 0x1eabe8 "foo_var.jv"
(top-gdb) n
782		      value_release_to_mark (mark);
(top-gdb) p *v
$8 = {lval = lval_memory, modifiable = 1, location = {address = 0x90904,
    ...}, offset = 16, bitsize = 0, bitpos = 0, frame_addr = 0,
  type = 0x1e7710, enclosing_type = 0x1e7710, next = 0x1ea6f8,
  substring_addr = {memaddr = 0xea890, ...}, regno = -1, lazy = 1 '\001',
  optimized_out = 0 '\000', embedded_offset = 0, pointed_to_offset = 0,
  bfd_section = 0x0, aligner = {...}}
(top-gdb)p *(struct type *)v->type
$9 = {code = TYPE_CODE_INT, name = 0x1e7754 "int", tag_name = 0x0, length = 4,
    upper_bound_type = 0, lower_bound_type = 0, ..., cv_type = 0x1e7710,
  flags = 0, nfields = 0, fields = 0x0, ..., type_specific = {
    arg_types = 0x0, cplus_stuff = 0x0}}
(top-gdb)p *v->next
$10 = {lval = lval_memory, modifiable = 1, location = {address = 0x90904,
     ...}, offset = 0, bitsize = 0, bitpos = 0, frame_addr = 0,
  type = 0x1e7a3c, enclosing_type = 0x1e7a3c, next = 0x0,
  substring_addr = {memaddr = 0xea890, ...}, regno = -1, lazy = 1 '\001',
  optimized_out = 0 '\000', embedded_offset = 0, pointed_to_offset = 0,
  bfd_section = 0x0, aligner = {...}}
(top-gdb) p *(struct type *)v->next->type
$11 = {code = TYPE_CODE_STRUCT, name = 0x0, tag_name = 0x1ea390 "foo", 
    length = 20, upper_bound_type = 0, lower_bound_type = 0, ...,
  cv_type = 0x1e7a3c, flags = 0, nfields = 5, fields = 0x0x1e7ad4,
  vptr_basetype = 0x0, vptr_fieldno = -1, type_specific = {
    arg_types = 0x13c120, cplus_stuff = 0x13c120}}
(top-gdb)

Here's teh source of the test program (the DOS-specific function
getch() reads a single character from the console device in binary
mode):

#include <float.h>
#include <math.h>
#include <stdio.h>

int main (int argc, char *argv[])
{
  volatile double a = M_SQRT2;
  struct foo {
    int iv;
    double dv;
    unsigned flag1:1;
    unsigned flag2:2;
    int jv;
  } foo_var;

  printf ("a squared = %f (should be 2.0)\n", a * a);
  a *= argc + 1;
  getch ();
  printf ("10 log10 (0.5) returns %f (should be -3)\n",
	  10 * log10 (1.0/(a*a)));
  argc = a * a;
  foo_var.iv = argc + 2;
  foo_var.jv = argc + 3;
  if (foo_var.iv < 10)
    foo_var.flag1 = 1;
  if (foo_var.jv < 100)
    foo_var.flag2 = 2;
  return 0;
}

Re: Hardware watchpoints

[Eli Zaretskii]

> I wonder, would it be possible to watch expressions like foo.x by
> having can_use_hardware_watchpoint ignore lval_memory values which are
> still lazy?  If a value is lazy, that means GDB never actually fetched
> it, but instead just used its address.

Could you suggest a quick hack to test whether this works?  If so, I
could try to see if that solvces the problem (and whether it introduces
new ones ;-).

As far as I remember from when I looked at this issue,
can_use_hardware_watchpoint is not the only place where it comes into
play: the other place is where GDB actually inserts the watchpoints.
What happens there is that GDB asks to watch a region the size of the
whole struct (or array, as the case may be), and any reasonable
implementation will refuse that, at least on x86.  (go32-nat.c has a
provision for watching up to 16-byte-long regions, but that's all.)

> Evaluating the expression foo.x, I think, produces two values: one for
> 'foo', which is lazy, and a second for the '.x' member of the first
> value, which is no longer lazy.

The question is: what happens for foo->x.  Since foo can changein this
case, GDB has to watch both foo and foo->x.  But it does NOT have to
watch *foo.
From jimb@cygnus.com Wed Oct 20 09:35:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: hjl@lucon.org (H.J. Lu), gdb@sourceware.cygnus.com
Subject: Re: Hardware watchpoints
Date: Wed, 20 Oct 1999 09:35:00 -0000
Message-id: <npvh82htxn.fsf@zwingli.cygnus.com>
References: <np3dv6k64w.fsf@zwingli.cygnus.com> <19991019235249.917DC1B494@ocean.lucon.org> <199910201401.KAA28719@mescaline.gnu.org>
X-SW-Source: 1999-q4/msg00067.html
Content-length: 2096

> > Evaluating the expression foo.x, I think, produces two values: one for
> > 'foo', which is lazy, and a second for the '.x' member of the first
> > value, which is no longer lazy.
> 
> The question is: what happens for foo->x.  Since foo can changein this
> case, GDB has to watch both foo and foo->x.  But it does NOT have to
> watch *foo.

Evaluating foo->x, I believe the values on the chain would be foo (not
lazy), and foo->x (not lazy).  So that would work correctly.

Even evaluating (*foo).x, I believe you'd get foo (not lazy), *foo
(lazy), and (*foo).x (not lazy).  So that would work too.


>Could you suggest a quick hack to test whether this works?  If so, I
>could try to see if that solvces the problem (and whether it introduces
>new ones ;-).

Here's an untested patch:

Index: breakpoint.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/breakpoint.c,v
retrieving revision 1.251
diff -c -c -b -F'^(' -r1.251 breakpoint.c
*** breakpoint.c	1999/09/30 03:29:33	1.251
--- breakpoint.c	1999/10/20 16:34:30
***************
*** 858,864 ****
  	    for (; v; v = v->next)
  	      {
  		/* If it's a memory location, then we must watch it.  */
! 		if (v->lval == lval_memory)
  		  {
  		    CORE_ADDR addr;
  		    int len, type;
--- 858,865 ----
  	    for (; v; v = v->next)
  	      {
  		/* If it's a memory location, then we must watch it.  */
! 		if (v->lval == lval_memory
! 		    && ! v->lazy)
  		  {
  		    CORE_ADDR addr;
  		    int len, type;
***************
*** 5050,5056 ****
       hardware watchpoint for the constant expression.  */
    for (; v; v = v->next)
      {
!       if (v->lval == lval_memory)
  	{
  	  CORE_ADDR vaddr = VALUE_ADDRESS (v) + VALUE_OFFSET (v);
  	  int       len   = TYPE_LENGTH (VALUE_TYPE (v));
--- 5051,5058 ----
       hardware watchpoint for the constant expression.  */
    for (; v; v = v->next)
      {
!       if (v->lval == lval_memory
! 	  && ! v->lazy)
  	{
  	  CORE_ADDR vaddr = VALUE_ADDRESS (v) + VALUE_OFFSET (v);
  	  int       len   = TYPE_LENGTH (VALUE_TYPE (v));
From capveg@cs.umd.edu Wed Oct 20 10:17:00 1999
From: Rob <capveg@cs.umd.edu>
To: "Peter.Schauer" <Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE>
Cc: capveg@cs.umd.edu (Rob), gdb@sourceware.cygnus.com, capveg@cs.umd.edu
Subject: Re: fix to noexec_user_stack on solaris 2.{6,7} 
Date: Wed, 20 Oct 1999 10:17:00 -0000
Message-id: <199910201715.NAA12493@xor.cs.umd.edu>
References: <199910200839.KAA17702@reisser.regent.e-technik.tu-muenchen.de>
X-SW-Source: 1999-q4/msg00068.html
Content-length: 1102

In message < 199910200839.KAA17702@reisser.regent.e-technik.tu-muenchen.de >, "Pe
ter.Schauer" writes:
>This will break calling of functions that return a structure or union.
>
>As per sparc calling conventions the call must looks like this:
>
>        call fun,0
>        nop
>        unimp <size of returned struct>
>
>Setting CALL_DUMMY_LOCATION to AT_ENTRY_POINT doesn't handle this case.
>
>When I was looking at the problem a long time ago, I had no idea how to
>solve it properly.

Just so I am clear on how this breaks:
gdb successfully makes the call and returns, but if the return type
is a struct or union, the size is not correctly reported.  With an
incorrect size, you can look into the internals of the struct.

Is that right?  If so, I think I am just going to apply the patch to my
systems, and be done with it. (Read: "users be damned" :)

Does anyone have any good pointers to information on Sparc calling 
conventions?
I have the "Sparc Assembly Reference Manual" that comes with the big solaris
documentation set, but I find it relatively useless.

Thanks for the help,

- Rob
.