From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18284 invoked by alias); 22 Feb 2011 13:27:35 -0000 Received: (qmail 18274 invoked by uid 22791); 22 Feb 2011 13:27:34 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,TW_RB,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 22 Feb 2011 13:27:29 +0000 Received: (qmail 6776 invoked from network); 22 Feb 2011 13:27:27 -0000 Received: from unknown (HELO scottsdale.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 22 Feb 2011 13:27:27 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: [unavailable regs/locals, 0/11] Introduction Date: Tue, 22 Feb 2011 13:28:00 -0000 User-Agent: KMail/1.13.5 (Linux/2.6.35-25-generic; KDE/4.6.0; x86_64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201102221327.22636.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-02/txt/msg00582.txt.bz2 This series mainly teaches GDB about unavailable/uncollected args/locals properly. Currently, GDB knows about, and handles gracefuly unavailable globals, but since the registers unavailable-ness hasn't been glued yet with values and frames, any local whose location is dependent on an unavailable register will get either miscomputed, printed as garbage, or throw an error instead of printing a graceful "". E.g., I've placed a tracepoint on line 57, and collected nothing: 56 void *thread_function0(void *arg) { 57 int my_number = (long) arg; 58 volatile int *myp = (volatile int *) &args[my_number]; 59 60 /* Don't run forever. Run just short of it :) */ 61 while (*myp > 0) 62 { 63 (*myp) ++; 64 usleep (1); /* Loop increment. */ (gdb) trace thread_function0 Tracepoint 2 at 0x400752: file threads.c, line 57. (gdb) tstart (gdb) c Continuing. ^C Program received signal SIGINT, Interrupt. (gdb) tstop (gdb) tfind Found trace frame 0, tracepoint 2 #0 thread_function0 (arg=) at threads.c:57 57 register int my_number = (long) arg; (gdb) info registers rax 0x0 0 rbx 0x0 0 rcx 0x0 0 rdx 0x0 0 rsi 0x0 0 rdi 0x0 0 rbp 0x0 0x0 rsp 0x0 0x0 r8 0x0 0 r9 0x0 0 r10 0x0 0 r11 0x0 0 r12 0x0 0 r13 0x0 0 r14 0x0 0 r15 0x0 0 rip 0x400752 0x400752 eflags 0x0 [ ] cs 0x0 0 ss 0x0 0 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 (gdb) Inspecting the traceframe, one can see above that gdbserver infers the $PC from the tracepoint address, but all other registers are shown as 0, which is wrong. We really don't know their value. If one prints the locals in this case, we'll see bogus values: (gdb) info locals my_number = 0 myp = We don't really know my_number's value, so '0' is wrong and misleading. Notice: (gdb) info scope thread_function0 Scope for thread_function0: Symbol arg is a variable at frame base reg $rsp offset 8+-56, length 8. Symbol my_number is a variable in $rbx, length 4. Symbol myp is a variable at frame base reg $rsp offset 8+-40, length 8. So not even myp is correct: (gdb) p $rsp $2 = (void *) 0x0 (gdb) p &arg $3 = (void **) 0xffffffffffffffe8 that's 0 + -40. Obviously not the correct address of that local. The series fixes this by glueing register unavailable-ness with value unavailable-ness, and then value unavailable-ness with frame unavailable-ness. Midway through the series, since GDB will be able to distinguish a register value zero from an unavailable register, GDB will start throwing errors whenever such register values are used in computations. The second part of the series makes GDB handle that gracefuly when necessary (particularly, when the PC itself is unavailable). Tested on x86_64-linux, native and gdbserver. No regressions, and the new tests pass cleanly. -- Pedro Alves