From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Kettenis To: ac131313@cygnus.com Cc: gdb@sourceware.cygnus.com Subject: Re: Moving Linux-specific stuff out of i386-tdep.c Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003091639.RAA23819@landau.wins.uva.nl> References: <200003082121.e28LLRu05681@delius.kettenis.local> <38C7AFC7.9F29EE49@cygnus.com> X-SW-Source: 2000-q1/msg00650.html Date: Fri, 10 Mar 2000 01:05:59 +1100 From: Andrew Cagney 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 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 * 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 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