From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3360 invoked by alias); 27 Jun 2004 17:39:02 -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 3353 invoked from network); 27 Jun 2004 17:39:01 -0000 Received: from unknown (HELO ns1.xcllnt.net) (209.128.86.226) by sourceware.org with SMTP; 27 Jun 2004 17:39:01 -0000 Received: from dhcp50.pn.xcllnt.net (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.12.11/8.12.11) with ESMTP id i5RHcwwC014294; Sun, 27 Jun 2004 10:38:58 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp50.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp50.pn.xcllnt.net (8.12.11/8.12.11) with ESMTP id i5RHcwUm007989; Sun, 27 Jun 2004 10:38:58 -0700 (PDT) (envelope-from marcel@dhcp50.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp50.pn.xcllnt.net (8.12.11/8.12.11/Submit) id i5RHcsRj007988; Sun, 27 Jun 2004 10:38:54 -0700 (PDT) (envelope-from marcel) Date: Sun, 27 Jun 2004 17:39:00 -0000 From: Marcel Moolenaar To: Mark Kettenis Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH] Add libkvm interface support for NetBSD/i386 and OpenBSD/i386 Message-ID: <20040627173854.GA7904@dhcp50.pn.xcllnt.net> References: <200406271623.i5RGN4Hd007746@elgar.kettenis.dyndns.org> <20040627163414.GB7790@dhcp50.pn.xcllnt.net> <200406271701.i5RH1wWJ007924@elgar.kettenis.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200406271701.i5RH1wWJ007924@elgar.kettenis.dyndns.org> User-Agent: Mutt/1.4.2.1i X-SW-Source: 2004-06/txt/msg00604.txt.bz2 On Sun, Jun 27, 2004 at 07:01:58PM +0200, Mark Kettenis wrote: > > Question: since this will do backtraces in the kernel, are there > plans to improve the frame sniffers (or frame sniffer framework) > to allow this code to add a sniffer for trapframes so that it's > possible to trace across them (if applicable) and also to improve > the termination of traces in the context of non-standard frames? > > Defenitely. It should be pretty easy to add unwinders for trap and > interrupt frames. In a sense, yes. I needed to add a sniffer in some other context, but had to tweak the framework a bit to allow me to add the sniffer before the last sniffer (i.e. the default sniffer). Without that tweak the default sniffer was tried before mine and since the default sniffer always takes the frame, mine ended up not being used at all. Not a big issue, but something that requires a bit of thought and rewrite to work well in a more dynamic context. In my case the following hack sufficed: /* Insert a predicate before the last in the table. */ static void penultimate_predicate (struct frame_unwind_table *table, frame_unwind_sniffer_ftype *sniffer) { if (table->nr > 0) { table->sniffer = xrealloc (table->sniffer, (table->nr + 1) * sizeof (frame_unwind_sniffer_ftype *)); table->sniffer[table->nr] = table->sniffer[table->nr - 1]; table->sniffer[table->nr - 1] = sniffer; table->nr++; } else append_predicate(table, sniffer); } :) > Termination of traces is a bit of an issue. If there is a fool-proof > way to detect the end of a frame-chain, then we should defenitely use > it. When debugging the kernel you'd probably want to terminate on > frames that cross the protection boundary between user-space and > kernel-space. I think the frame sniffers can help here. However, I don't think GDB should have all the various and weird sniffers embedded, because they tend to be highly volatile. For example: some frames are known only by the bounds of the function and thus can be detected only by the PC. This can be different for every recompilation of the system to which it applies (in theory). In general it requires knowledge that goes beyond the ABI and runtime specs. and it might be a good idea to off-load this to MI or CLI clients or provide hooks so that one can easily "plug" these in. The same would apply to the unwind library on ia64. It's easy enough to label a frame with unwind information, but knowing what to do with such a frame may require more knowledge than what you like the unwind library to have. Hooks to allow some "external" code to deal with it would probably be the most flexible solution. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net