From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8872 invoked by alias); 4 Mar 2006 14:58:00 -0000 Received: (qmail 8864 invoked by uid 22791); 4 Mar 2006 14:58:00 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Sat, 04 Mar 2006 14:57:58 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FFYCh-0005U3-Ar; Sat, 04 Mar 2006 09:57:55 -0500 Date: Sat, 04 Mar 2006 15:07:00 -0000 From: Daniel Jacobowitz To: Alexandre Oliva Cc: Mark Kettenis , gdb-patches@sources.redhat.com Subject: Re: Support Dwarf3 DW_CFA_val_* expressions Message-ID: <20060304145755.GB20187@nevyn.them.org> Mail-Followup-To: Alexandre Oliva , Mark Kettenis , gdb-patches@sources.redhat.com References: <200603041017.k24AHjh7024812@elgar.sibelius.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-03/txt/msg00098.txt.bz2 On Sat, Mar 04, 2006 at 09:01:43AM -0300, Alexandre Oliva wrote: > > It's also good to have a few testcases, > > but I don't completely understand the testcases :( > > You're not alone in that feeling, I assure you :-) Like Mark, I am happier with the code than the testcases. In fact, I'd rather not have the tests at all than have something quite so overkill. And you're not correct that older GCCs could run them far enough to test; they'll fail to build because of the use of __attribute__((cleanup)) (and the fact that dejagnu treats warnings as fatal). You ought to be able to test this much more simply, if you wire it up to the bits in gdb.asm. I'm thinking something like this: gdbasm_declare foo gdbasm_enter gdbasm_call bar .cfi_startproc .cfi_return_column 0 .cfi_undefined 0 gdbasm_leave .cfi_endproc gdbasm_end foo You ought to be able to backtrace from the call statement, without unwind info, and you ought to be unable to backtrace from the epilogue, where the dwarf2 unwinder will kick in and say you've hit the end of the stack. Whether bar has a signal augmentation or not will determine whether you can backtrace from it to foo's caller or not. Unfortunately if you want to put the signal augmentation on bar you'll also need unwind info for it; I guess that would require an addition to the gdb.asm bits. Then, just refuse to test if the testcase doesn't assemble. I'm sure it won't work for some platforms, and we'll have to add some skips in the .exp file, but it ought to get enough of the current ELF/dwarf platforms to be interesting, don't you think? -- Daniel Jacobowitz CodeSourcery