From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29969 invoked by alias); 7 Aug 2003 14:58:59 -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 29957 invoked from network); 7 Aug 2003 14:58:57 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.131) by sources.redhat.com with SMTP; 7 Aug 2003 14:58:57 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 23E3F2B7F; Thu, 7 Aug 2003 10:58:48 -0400 (EDT) Message-ID: <3F326928.3020502@redhat.com> Date: Thu, 07 Aug 2003 14:58:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: Michal Ludvig , gdb Subject: Re: [testsuite & dwarf2] How to handle store.exp failure on AMD64? References: <3F3212B7.8060003@suse.cz> <20030807135035.GA28000@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-08/txt/msg00099.txt.bz2 > On Thu, Aug 07, 2003 at 10:49:59AM +0200, Michal Ludvig wrote: > >> 4) let GDB pretend that all registers have the same value unless said >> otherwise later in the .debug_frame and convince GCC to put a note when >> their value is overwritten. >> >> Opinions? > > > See the archives of this list, from about a month ago. I discussed > this with Richard but never got around to writing a patch. And I forgot to commented on the thread also :-( There are several bugs: - An architecture should mark a limited set of registers as, for want of a better phrase, `always unwind'. System registers, for instance, would fall into that category. No preserve registers, however, are a more interesting problem. - GCC should be generate, and GDB should consume, more complete variable location information. If a variable isn't preserved across a function call then GCC/GDB should report the variable as being unavailable. - GCC -O0 should should not eliminate variables, and should preserve all variables across function calls. Given that is compiled with -O0, I think GCC is failing on count #3 here. Andrew PS: My TODO list includes start a, er GCC vs GDB flame war about -O levels. PPS: This is just the start. Higher optimization levels mean that GCC will need to generate debug info describing how to recover eliminated variables.