From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24088 invoked by alias); 20 Apr 2010 19:26:02 -0000 Received: (qmail 24079 invoked by uid 22791); 20 Apr 2010 19:26:01 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,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, 20 Apr 2010 19:25:58 +0000 Received: (qmail 7105 invoked from network); 20 Apr 2010 19:25:56 -0000 Received: from unknown (HELO macbook-2.local) (stan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 20 Apr 2010 19:25:56 -0000 Message-ID: <4BCDFFBF.6030403@codesourcery.com> Date: Tue, 20 Apr 2010 19:26:00 -0000 From: Stan Shebs User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Stan Shebs CC: "gdb-patches@sourceware.org" Subject: Re: [PATCH] Dwarf location expressions, tracing and printing References: <4BC7B823.6040406@codesourcery.com> In-Reply-To: <4BC7B823.6040406@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 2010-04/txt/msg00633.txt.bz2 Stan Shebs wrote: > This patch solves a number of problems related to variables with > Dwarf2 location expressions - which these days, means just about every > local in optimized code. :-) Perhaps the most interesting part is > that I finally got tired of working blind and filled out description > location functions, so now both "info scope" and "info address" have > quite a lot of say about variables. Try things like "info scope > handle_inferior_event" to get some truly awesome verbiage. :-) > > Since there's a lot of new code here, I'll leave it up for a couple > days before committing. > Just as a heads-up, this patch exposes a major hole in our tracepoint machinery when running testsuite with gdbserver - namely that agent expressions don't have a way to deal with registers that are larger than 64 bits. This crops up in gdb.trace/collection.exp:reglocal_test_func on x86, in which the local floats are assigned to $stX registers, which are 10 bytes long. gdbserver properly chokes on any attempt to push these on the expression stack (although one might argue that it should be a tracing rather than internal error). Previously, the registers were incorrectly numbered to 4-byte registers, which resulted in four FAILs when printing collected floats, but nothing worse. I went ahead and committed the patch anyway, because the fix/workaround isn't obvious, and it's a design problem elsewhere. Alternatives include: 1) Make the expression stack wider. The existing target-side implementations are designed around the 64-bit assumption, so there would be some messy fixing-up with sign extensions and the like. 2) Generate bytecodes to handle larger registers as multiple pieces. 3) Disallow larger registers in expressions. 4) Stub out that part of the testsuite. :-) Stan