From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5601 invoked by alias); 6 Nov 2004 14:34:47 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 5540 invoked from network); 6 Nov 2004 14:34:45 -0000 Received: from unknown (HELO beyond.lidskialf.net) (62.3.233.115) by sourceware.org with SMTP; 6 Nov 2004 14:34:45 -0000 Received: from monstrousfish (monstrousfish [172.16.1.2]) by beyond.lidskialf.net (Postfix) with ESMTP id 79A854670FE for ; Sat, 6 Nov 2004 14:34:44 +0000 (GMT) From: Andrew de Quincey To: gdb@sources.redhat.com Subject: GDB 6.2.1 with powerpc platform and uclibc and user breakpoint problem Date: Sat, 06 Nov 2004 14:34:00 -0000 User-Agent: KMail/1.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200411061434.45201.adq_dvb@lidskialf.net> X-SW-Source: 2004-11/txt/msg00048.txt.bz2 Hi, I've having some serious problems with GDB 6.2.1. I am remote debugging a ppc 405 platform based on the latest uclibc snapshot. So GDB itself is running on i386 targetted at the ppc-405, whilst gdbserver is a native ppc-405 application running on the target platform. Oh - gcc is v3.3.4, built along with uclibc using the "toolchain" scripts available on www.uclibc.org. The symptoms are user breakpoints do not work. However, GDB internal breakpoints *do* work. I've verified that the kernel (2.4.20) responds correctly to breakpoints by adding in tracing to the trap handlers. I can't believe this is a problem with gdb itself. And other people have uclibc working with GDB on other platforms. So my only conclusion is that I'm doing something really stupid - but I don't know what! I built GDB with: "./configure --target=ppc-405-linux; make" I build gdbserver with "CC=ppc-405-linux-gcc ./configure --host=ppc-405-linux; make" The test program is as follows - it performs a small calculation then intentionally generates a segfault. I am putting a breakpoint on the main() function, so it should stop before the segfault. This does not happen. #include #include #include int main(int argc, char* argv[]) { int64_t sum; int x; int y; char* tmp = (void*) 0; x = x * 20; y = x; *tmp = 0; sum = -2000; x = atoi(argv[1]); printf("%lli\n", sum >> x); } I should also mention that I cross compiled GDB for the target platform and ran it natively - with the same problem!!! I also tried gdb 6.1.1 just in case - the same results. Oh, I've also tried putting breakpoints on other lines - not just on "main()" - they don't work either. I added protocol tracing to gdbserver. In the following, RX is a packet received from gdb, whilst TX is a packet sent by gdbserver: --- I connect to the remote target with target remote ip:port RX: Hc-1 TX: OK RX: qC TX: RX: qOffsets TX: RX: ? TX: T0501:7ffffb70;40:3000108c; RX: Hg0 TX: OK RX: g TX: 000000007ffffb7000000000000000000000000000000000000000000000000000000000000000000000000000000 RX: mfffffffc,c TX: E01 RX: mfffffffc,c TX: E01 RX: m10010904,b0 TX: 00000001000000010000000c1000036c0000000d1000089c000000041000012800000005100002680000000610000 RX: qSymbol:: TX: OK -- At this point, GDB stops at the _dl_boot function. I type "break main" and then "c" RX: Z0,10000548,4 TX: RX: m10000548,4 TX: 38000000 RX: X10000548,0: TX: RX: M10000548,4:7d821008 TX: OK -- here GDB read the contents of 0x10000548 - my breakpoint - and replaces it with the trap instruction (0x7d821008) RX: m300018d4,4 TX: 801c005c RX: M300018d4,4:7d821008 TX: OK -- here GDB read the contents of 0x300018d4 - an internal breakpoint on the _dl_debug_state function - and replaces it with the trap instruction (0x7d821008). RX: vCont? X: vCont;c;C;s;S RX: vCont;c -- this is my continue command. It runs until GDB hits the following breakpoint. TX: T0501:7ffff4e0;40:300018d4; -- this is the internal breakpoint on _dl_debug_state being triggered. I see this in my kernel tracing in the trap handlers. RX: m10000548,4 TX: 7d821008 RX: M10000548,4:38000000 TX: OK RX: m300018d4,4 TX: 7d821008 RX: M300018d4,4:801c005c TX: OK -- GDB is clearing the breakpoints *INCLUDING MY USER BREAKPOINT* - it has removed the trap instruction and set it back to 0x38000000. why is it doing this!?! RX: m10010904,b0 TX: 00000001000000010000000c1000036c0000000d1000089c000000041000012800000005100002680000000610000 RX: m30005004,4 TX: 00000000 RX: vCont;s TX: T0b01:7ffffa60;40:1000056c; RX: g TX: 000000007ffffa6000000000000000017ffffb747ffffb7c1000036c1000089c3001d2730000000000000000300d0 RX: m30027074,c TX: 480b5cb57c601b787c030378 RX: m7ffffa68,4 TX: 00000001 RX: m7ffffa6c,4 TX: 7ffffb74 -- GDB has fallen into the segmentation violation here. I type "c" to continue. RX: m10000548,4 TX: 38000000 RX: M10000548,4:7d821008 TX: OK RX: m300018d4,4 TX: 801c005c RX: M300018d4,4:7d821008 TX: OK RX: vCont;C0b -- GDB restores the trap handlers. It seems to be restoring the right values - this time. The "RX: M10000548,4:7d821008" command is writing the trap instruction back out to memory for my user breakpoint. Can anyone suggest something I can try out?