From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9536 invoked by alias); 9 May 2003 19:36:47 -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 9310 invoked from network); 9 May 2003 19:36:43 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (62.163.169.212) by sources.redhat.com with SMTP; 9 May 2003 19:36:43 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.6/8.12.5) with ESMTP id h49JaYXX000623; Fri, 9 May 2003 21:36:34 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) by elgar.kettenis.dyndns.org (8.12.6/8.12.6) with ESMTP id h49JaYXI007645; Fri, 9 May 2003 21:36:34 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.6/8.12.6/Submit) id h49JaXrJ007642; Fri, 9 May 2003 21:36:33 +0200 (CEST) Date: Fri, 09 May 2003 19:36:00 -0000 Message-Id: <200305091936.h49JaXrJ007642@elgar.kettenis.dyndns.org> From: Mark Kettenis To: roland@redhat.com CC: gdb@sources.redhat.com In-reply-to: <200305090945.h499jTH13137@magilla.sf.frob.com> (message from Roland McGrath on Fri, 9 May 2003 02:45:29 -0700) Subject: Re: gdb/dwarf-frame.c References: <200305090945.h499jTH13137@magilla.sf.frob.com> X-SW-Source: 2003-05/txt/msg00150.txt.bz2 Date: Fri, 9 May 2003 02:45:29 -0700 From: Roland McGrath (Hi Mark! It's been too long since we hacked together.) (Hi Roland! I've drifted away a bit from glibc and the Hurd :-(.) [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. dwarf2cfi.c currently has more complete support for DWARF CFI, but suffers from some design flaws, which probably makes it unusable for debugging any serious project. 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? Daniel is right here. I'm busy writting the support for .eh_frame sections. I just left them out since they complicate matters quite a bit. 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. It certainly is my intention to make it possible, although It's not clear how things should be glued together. I've seen your kernel patches and it seems as if there are two possibilities: 1. Reading the complete DSO from target memory, and somehow turning it in a bfd. That would make it possible to use the existing symbol reading machinere to read symbols and .eh_frame info. 2. Write a symbol reader that uses the run-tume dynamic linker (struct r_debug, struct link_map) to locate the dynamic section of the shared object, and uses it to read the relevant loaded sections of the DSO from the target and interpret those bits. If I'm not mistaken, the latter would also allow us to construct a minimal symbol table for DSO's even if the we don't have access to an on-disk file. We'll probably need some serious hacking on GDB's shared library support to make this all possible. Mark