From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31229 invoked by alias); 7 Aug 2003 15:02:01 -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 31222 invoked from network); 7 Aug 2003 15:02:01 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 7 Aug 2003 15:02:01 -0000 Received: from drow by nevyn.them.org with local (Exim 4.20 #1 (Debian)) id 19kmHB-0007ge-2a for ; Thu, 07 Aug 2003 11:02:01 -0400 Date: Thu, 07 Aug 2003 15:02:00 -0000 From: Daniel Jacobowitz To: gdb Subject: Re: [testsuite & dwarf2] How to handle store.exp failure on AMD64? Message-ID: <20030807150201.GA29511@nevyn.them.org> Mail-Followup-To: gdb References: <3F3212B7.8060003@suse.cz> <20030807135035.GA28000@nevyn.them.org> <3F326928.3020502@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F326928.3020502@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-08/txt/msg00100.txt.bz2 On Thu, Aug 07, 2003 at 10:58:48AM -0400, Andrew Cagney wrote: > >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. I'm not talking about variable location information. I'm talking about register unwind information; and Richard's claim that the default should be unmodified makes sense in the context of unwinding. Variable locations are a different problem. A serious one, maybe, but unrelated. > - 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. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer