From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30856 invoked by alias); 1 Jan 2007 20:02:55 -0000 Received: (qmail 30848 invoked by uid 22791); 1 Jan 2007 20:02:54 -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; Mon, 01 Jan 2007 20:02:50 +0000 Received: from drow by nevyn.them.org with local (Exim 4.63) (envelope-from ) id 1H1TMu-0004zl-26; Mon, 01 Jan 2007 15:02:48 -0500 Date: Mon, 01 Jan 2007 20:02:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: gdb-patches@sourceware.org Subject: Re: [patch RFC] Re: Notes on a frame_unwind_address_in_block problem Message-ID: <20070101200248.GA19073@nevyn.them.org> Mail-Followup-To: Mark Kettenis , gdb-patches@sourceware.org References: <20060706222157.GA1377@nevyn.them.org> <200607132020.k6DKKCSB023812@elgar.sibelius.xs4all.nl> <20060718183910.GB17864@nevyn.them.org> <20070101191927.GA14930@nevyn.them.org> <200701011954.l01Js85r031019@brahms.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200701011954.l01Js85r031019@brahms.sibelius.xs4all.nl> User-Agent: Mutt/1.5.13 (2006-08-11) 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-01/txt/msg00030.txt.bz2 On Mon, Jan 01, 2007 at 08:54:08PM +0100, Mark Kettenis wrote: > Well, I really can't say I like it. The problem is that it's been > several months since we last discussed this problem, so I'll have to > start to think again from scratch :(. Isn't it just a matter of Yeah, sorry about that. Anyway, I'm happy to discuss alternatives; I don't like it much either. > making sure we set the right function address for signal trampolines? > That is, shouldn't we have a dwarf2_signal_frame_this_id() that > chooses a more sensible code address than frame_func_unwind()? That would fix the failing tests, but I'm worried about problems elsewhere. That's what I did in the patch I posted in July, I think. But get_frame_func would still return different values depending on whether the frame was topmost or not. That's called all over GDB - I can't figure out whether it will leave other bugs for us to stumble on later. > Optimist! We'll only have to wait for the GCC/glibc/kernel people to > come up with the next smart hack that they don't bother to test GDB > with and you'll have lots of failures to fix again ;-) Well yeah :-) But the first step in keeping up is definitely catching up. > But we have no stand-alone testcase. You really need the right > version of glibc to be able to test this. Could you come up with a > testcase that works everywhere, or at least on all targets? Hmm... I don't think it's possible, but it depends what qualifier you meant to put on "all targets". The only way I can see to do it would be with hand-written assembly and CFI and stack manipulation. I might be able to write a test which worked on all x86-64 systems and pretended to have create a signal frame, if that's what you wanted. -- Daniel Jacobowitz CodeSourcery