From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6814 invoked by alias); 16 Dec 2002 17:27:18 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 6805 invoked from network); 16 Dec 2002 17:27:16 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 16 Dec 2002 17:27:16 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18O0tr-00049d-00; Mon, 16 Dec 2002 13:27:35 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18Nz2L-0004vM-00; Mon, 16 Dec 2002 12:28:13 -0500 Date: Mon, 16 Dec 2002 09:40:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Michal Ludvig , GDB Patches Subject: Re: [RFA] Artifical dwarf2 debug info Message-ID: <20021216172813.GA18150@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Michal Ludvig , GDB Patches References: <3DFBD14C.7090501@suse.cz> <3DFE0741.7020902@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DFE0741.7020902@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-12/txt/msg00481.txt.bz2 On Mon, Dec 16, 2002 at 12:02:57PM -0500, Andrew Cagney wrote: > >Hi all, > >this long patch provides a fix for a very annoying fact, that GDB on > >x86-64 can't do backtraces from hand-optimized assembler functions (that > >applies for example to glibc's memset, str*, etc as well as to syscall > >wrappers). > >This is caused by the lack of a valid debug_frame/eh_frame FDE entry for > >such a function (noone really writes .debug_frame section in his assembler > >code :-) > > > >My approach to fix this behaviour is based on the fortunate fact, that > >most of those affected glibc's functions don't touch the stack at all, so > >creating an artifical FDE for them is easy. > > If I understand this correctly, you've created create dwarf2cfi info for > a function that has no such info. That way the dwarf2cfi code can > unwind a function that doesn't actually have CFI? That's right. > If that is the case then I don't think this is either necessary or > correct. A `struct frame_info' allows frame specific unwind functions - > at present only dummy-frame and saved-regs-frame versions are > implemented, however the next ones to implement are cfi-frame (unwind > using CFI info) and regs-frame (unwind using the register cache). > > For your problem, wouldn't it be better to, instead of creating fake CFI > info, implement custom frame unwind functions that handle your case? Hrm. What do you mean by regs-frame? If it's for the current frame wouldn't that be a frame which just doesn't unwind? As for this situation, and the similar one for i386... there are three unwind functions, to find the previous frame's registers, ID, and PC. For this case we just want to express a normal function call which saves no registers; pretty easy. But for i386 I'll want to express something which initially pushes a register, and then does some work, pops it, and does more work before returning. There's plenty of ways to express that but it seems to me that the most useful one would be to have essentially a glorified prologue reader which builds that description. Then the machinery to handle that description is - you guessed it - a standard CFI reader. It might be nice to someday split up the CFI parser and executer so that we could provide the description less obtusely, but I'd hate to see us duplicate the machinery. BTW, /* See description above. The previous frame's resume address. Save the previous PC in a local cache. */ frame_pc_unwind_ftype *pc_unwind; /* See description above. The previous frame's resume address. Save the previous PC in a local cache. */ frame_id_unwind_ftype *id_unwind; Second comment is a past-o? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer