From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9715 invoked by alias); 22 Dec 2005 15:26:18 -0000 Received: (qmail 9706 invoked by uid 22791); 22 Dec 2005 15:26:18 -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; Thu, 22 Dec 2005 15:26:17 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1EpSKd-000179-8B; Thu, 22 Dec 2005 10:26:15 -0500 Date: Fri, 23 Dec 2005 08:29:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: gdb-patches@sourceware.org Subject: Re: [commit] Fix OpenBSD/i386 and OpenBSD/amd64 kernel trapframe unwinders Message-ID: <20051222152615.GA4248@nevyn.them.org> Mail-Followup-To: Mark Kettenis , gdb-patches@sourceware.org References: <200512221409.jBME9L7W005129@elgar.sibelius.xs4all.nl> <20051222142013.GA3110@nevyn.them.org> <200512221520.jBMFK7fL029527@elgar.sibelius.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200512221520.jBMFK7fL029527@elgar.sibelius.xs4all.nl> 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: 2005-12/txt/msg00265.txt.bz2 On Thu, Dec 22, 2005 at 04:20:07PM +0100, Mark Kettenis wrote: > I've struggled with this for a while. Apart from adding DWARF2 CFI to > the kernel, there's no real alternative to matching function names. > And DWARF2 doesn't allow me to terminate the backtrace at the user to > kernel transition. Yes it does - what do you think inspired my patches for an undefined return address column? :-) They were for Linux's KGDB. Unless the OpenBSD kernel has a distressingly large number of entry points, the same thing should work there. It's only if you want to do something besides stop at the boundary that things get really complicated. > Simply matching the function names is of course > unacceptable, so I had to do something a bit more clever. If you look > at the sniffer for the unwinder, you see the following check: > > cs = frame_unwind_register_unsigned (next_frame, AMD64_CS_REGNUM); > if ((cs & I386_SEL_RPL) == I386_SEL_UPL) > return 0; > > This checks the Requested Protection Level, which is stored in the > lower two bits of %cs. When executing in the kernel, the RPL is 0, > for userland its 3. So we can reliably check whether we're in the > kernel or in userland. And I only check the magic function names when > the current frame is a kernel frame. I guess I should add a comment > in the code about that. Aha, I missed that. And we're OpenBSD targeted here, so if we're in kernel mode, it's a reasonably safe assumption that we're in the OpenBSD kernel. I'd appreciate a clarifying comment. > P.S. The new Xorg X11R6.9/X11R7.0 doesn't need any special patches > anymore since they now use dlopen(3) to load modules. Ooh, that's good news. The Linux kernel module loader still does, though - they've been talking about loading objects as shared libraries for years, but I don't think it's going to happen soon. -- Daniel Jacobowitz CodeSourcery, LLC