From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27879 invoked by alias); 9 May 2007 00:33:59 -0000 Received: (qmail 27869 invoked by uid 22791); 9 May 2007 00:33:59 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 09 May 2007 00:33:57 +0000 Received: (qmail 2134 invoked from network); 9 May 2007 00:33:55 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 9 May 2007 00:33:55 -0000 To: Caroline Tice Cc: gdb-patches@sourceware.org Subject: Re: Ping! [PATCH]: Tracking and reporting uninitialized variables References: <80EE31A6-4DF2-4D1F-B23D-8B814C1E6928@apple.com> <717BDA2E-D6FF-4AA5-B857-68BA5B140F5F@apple.com> From: Jim Blandy Date: Wed, 09 May 2007 00:33:00 -0000 In-Reply-To: <717BDA2E-D6FF-4AA5-B857-68BA5B140F5F@apple.com> (Caroline Tice's message of "Tue, 8 May 2007 09:26:35 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 2007-05/txt/msg00124.txt.bz2 Caroline Tice writes: >> As part of some work I have been doing on improving debugging of >> optimized code, I >> have created a GCC patch that tags variables it believes are >> uninitialized with a new >> Dwarf op (an extension), DW_OP_GNU_uninit. I have submitted that >> patch to the >> GCC patches list and am waiting for approval to commit it. I have >> also created the >> following gdb patch to recognize the new op and inform the user when >> a variable >> the user requests to see is uninitialized. >> >> I have tested this patch on some small testcases and I have run the >> gdb dejagnu >> testsuite with no regressions. I am new to submitting things to >> this list, so if there >> is anything else I ought to have done, please let me know >> (kindly!). Hi, Caroline. This seems like a nice patch. In a multi-piece location expression, can each piece be individually initialized or uninitialized? If that's so, then there should also be an 'initialized' member of 'struct dwarf_expr_piece', which gets set appropriately for each piece in a multi-piece location expression. Either way, the code for DW_OP_GNU_uninit should check that it's the last opcode in the piece or in the entire expression, as the DW_OP_reg* cases do. I think the 'struct dwarf_expr_context' member should be named simply 'initialized', instead of 'var_status'. The 'struct value' field should be named 'initialized', and the accessor functions should be named 'value_initialized' and 'set_value_initialized'. The comment in value.h actually needs to be filled in; the description should be thorough enough to allow someone who otherwise knows how GDB works to use those functions, without reading their definitions. I couldn't see from your patch why 'signed_address_type', 'unsigned_address_type', and 'add_piece' were made visible outside dwarf2expr.c; that should be left out of the patch if it's not needed. Have you filed a copyright assignment with the FSF?