From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26532 invoked by alias); 9 May 2003 09:45:33 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 26466 invoked from network); 9 May 2003 09:45:31 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.163.213.212) by sources.redhat.com with SMTP; 9 May 2003 09:45:31 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 2373C354C; Fri, 9 May 2003 02:45:30 -0700 (PDT) Received: (from roland@localhost) by magilla.sf.frob.com (8.11.6/8.11.6) id h499jTH13137; Fri, 9 May 2003 02:45:29 -0700 Date: Fri, 09 May 2003 09:45:00 -0000 Message-Id: <200305090945.h499jTH13137@magilla.sf.frob.com> From: Roland McGrath To: Mark Kettenis Cc: gdb@sources.redhat.com Subject: gdb/dwarf-frame.c Emacs: the Swiss Army of Editors. X-SW-Source: 2003-05/txt/msg00117.txt.bz2 (Hi Mark! It's been too long since we hacked together.) [Please note that I am not on the mailing list, so keep me CC'd directly.] I have been looking at the kettenis_i386newframe-20030419-branch gdb code. I've been told that the new dwarf-frame.c replaces the dwarf2cfi.c code that's on mainline. I don't know the guts of either or of DWARF2 itself well enough to compare them. What I have noticed is that dwarf-frame.c does not seem to handle the .eh_frame section, only the .debug_frame section. The dwarf2cfi.c code looks at both. As well as looking for the section, it needs to grok the "augmentation" values and different encodings used in .eh_frame, and I don't see any of that handled in the new code. Is this an intentional omission and if so what is the rationale? I think grokking .eh_frame sections in the absence of .debug_frame is a nice thing in general--it might give you at least some more helpful backtraces than otherwise when dealing with binaries without debugging info. But the particular reason it is of concern to me is that it's needed for unwinding PC values within the special kernel entrypoint page now being used in Linux on x86. glibc now uses this entrypoint code for every system call, and so any thread blocked in a system call (which most threads one looks at are when one starts looking) will have its PC inside this code and need to be able to unwind that frame-pointer-less leaf frame to produce a useful backtrace. This is magic kernel code for which there is never going to be debugging information, but for which we do have .eh_frame information we can get at. I am setting about attacking how we get at it in all the relevant cases, but I had been working from the assumption that upon locating some information in .eh_frame form (including "zR" augmentation and pcrel pointer encoding) it would plug easily into the DWARF2 unwinding machinery. If that's not so, it throws a monkey wrench into my plans. Thanks, Roland