Re: Moving Linux-specific stuff out of i386-tdep.c

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

   Date: Fri, 10 Mar 2000 01:05:59 +1100
   From: Andrew Cagney <ac131313@cygnus.com>

   Mark Kettenis wrote:

   > 2. Should I postpone creating the new -tdep.c file until after the
   >    release or not.  Andrew has been telling us to avoid gratuitous
   >    changes to make it easier to apply outstanding patches.  But on the
   >    other hand, after 5.0 is released, I hope to see a lot new patches
   >    generated against 5.0.  So creating the new file before 5.0 would
   >    make applying those new patches a lot easier.

   I guess its the sigtramp stuff.

Indeed.

   If the checkin was a straight cut/paste (without edits) I won't notice
   :-)
   Down the track, there will need to be ``i386-linux-tdep.h'' so that
   i386-linux-nat.c can include it.  (Hmm, with i386-linux-tdep.c, no
   wonder Eli raised a concern).

The 8.3 limit really prevents me from choosing a sensible name here.
So I'll leave the Linux code in i386-tdep.c for now.  If we ever come
up with a sensible way to reorganize the GDB sources we can reconsider
things.

Mark
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: hjl@lucon.org
Cc: gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Problems with hardware watchpoint on ia32.
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003091211.HAA19860@indy.delorie.com>
References: <20000307132401.A20282@valinux.com> <200003081008.FAA16481@indy.delorie.com> <20000308084304.A3150@lucon.org>
X-SW-Source: 2000-q1/msg00636.html
Content-length: 1704

Problem no.2: Read watchpoints break when they shouldn't.

Example (slightly modified test program posted by H.J. Lu):

$ cat wp.c
int a1;
int a2;
int a3;
int a4;
int a5;
int a6;

unsigned long long ulla1 = 0;
double da2 = 0;

int main (void)
{
  a2 = 12;
  a3 = 13;
  a4 = 14;
  a5 = 15;
  a6 = 16;
  a1 = 11;
  a2 = a4;

  ulla1 = 0x00000000ffffffffLL;
  da2 = 12;
  ulla1 = 0xffffffff00000000LL;

  return 0;
}

$ gcc -g -o wp wp.c
$ gdb wp
(gdb) watch a5
Hardware watchpoint 2: a5
(gdb) rwatch a5
Hardware read watchpoint 3: a5
(gdb) run
Starting program g:/gdbsnap/gdb-0222/gdb/wp
Hardware watchpoint 2: a5

Old value = 0
New value = 15
Hardware read watchpoint 3: a5

Value = 15
main () at wp.c: 16
16	a5 = 15;
(gdb)

Now, it might seem like a strange idea to put two watchpoints on the
same variable, but it is a very useful feature when each watchpoint
has a different condition.

Here's the patch:

2000-03-08  Eli Zaretskii  <eliz@is.elta.co.il>

	* breakpoint.c (bpstat_stop_status): Don't stop if a read
	watchpoint appears to break, but the watched value changed.


--- gdb/breakpoint.c~2	Wed Mar  8 19:20:28 2000
+++ gdb/breakpoint.c	Wed Mar  8 20:02:20 2000
@@ -2620,6 +2620,17 @@ bpstat_stop_status (pc, not_a_breakpoint
 	      /* Stop.  */
 	      break;
 	    case WP_VALUE_CHANGED:
+	      if (b->type == bp_read_watchpoint)
+		{
+		  /* Don't stop: read watchpoints shouldn't fire if
+		     the value has changed.  This is for targets which
+		     cannot set read-only watchpoints.  */
+		  bs->print_it = print_it_noop;
+		  bs->stop = 0;
+		  continue;
+		}
+	      ++(b->hit_count);
+	      break;
 	    case WP_VALUE_NOT_CHANGED:
 	      /* Stop.  */
 	      ++(b->hit_count);
From Timo.Ketola@Epec.fi Sat Apr 01 00:00:00 2000
From: Timo Ketola <Timo.Ketola@Epec.fi>
To: gdb@sourceware.cygnus.com
Subject: Remote Debugging
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38B4017A.2F64A9C3@Epec.fi>
X-SW-Source: 2000-q1/msg00382.html
Content-length: 984

Hi all,

I just subscribed to this list...

I'm adapting the gdb and the remote stub for our embedded system.
Debugging works already over a RS232 line but I have a couple of
questions for which I can't find an answer:

1) I want to be able to debug also over a CAN network. I think I have to
write a new interface for the gdb. Namely the getpkt and putpkt of the
remote.c should be reimplemented. But what is a clean way? Could someone
assist me a bit.

2) When I 'load' a new executable into the target the loading works well
but the symbols are not loaded. At the end of generic_load function
comment asks whether symbol_file_add function should be called. Is that
exactly the right thing to do?

3) How do I get a clean information about the load of the new executable
in the stub? Before a new executable is started (or an old one
restarted) the stub needs to do a couple of things (for example clean up
the stack).

Please, forgive me if the answers are too obvious...
--
Timo