From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12559 invoked by alias); 1 Jan 2007 20:27:00 -0000 Received: (qmail 12550 invoked by uid 22791); 1 Jan 2007 20:26:59 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO brahms.sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 01 Jan 2007 20:26:55 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.13.8/8.13.8) with ESMTP id l01KQkDP022216; Mon, 1 Jan 2007 21:26:46 +0100 (CET) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.13.8/8.13.8/Submit) id l01KQj6h022478; Mon, 1 Jan 2007 21:26:45 +0100 (CET) Date: Mon, 01 Jan 2007 20:27:00 -0000 Message-Id: <200701012026.l01KQj6h022478@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: drow@false.org CC: gdb-patches@sourceware.org In-reply-to: <20070101200248.GA19073@nevyn.them.org> (message from Daniel Jacobowitz on Mon, 1 Jan 2007 15:02:48 -0500) Subject: Re: [patch RFC] Re: Notes on a frame_unwind_address_in_block problem 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> <20070101200248.GA19073@nevyn.them.org> 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/msg00031.txt.bz2 > Date: Mon, 1 Jan 2007 15:02:48 -0500 > From: Daniel Jacobowitz > > > 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. But if you're calling get_frame_func() you've already got a frame, so you should know everything about it. The place to fix things is probably get_frame_address_in_block(). For one thing it's probably not a good idea to return an address that's lower than the code address in the frame ID. Or perhaps it is enough to look at the frame's type and simply call frame_pc_unwind for SIGTRAMP_FRAMEs. > 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. Hmm, sorry yes, a test that would work on all i386 or x86-64 target was what I actually meant.