From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11426 invoked by alias); 16 Apr 2003 21:04:56 -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 11417 invoked from network); 16 Apr 2003 21:04:55 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.169.160.245) by sources.redhat.com with SMTP; 16 Apr 2003 21:04:55 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 2C5B9354C; Wed, 16 Apr 2003 14:04:54 -0700 (PDT) Received: (from roland@localhost) by magilla.sf.frob.com (8.11.6/8.11.6) id h3GL4rp01982; Wed, 16 Apr 2003 14:04:53 -0700 Date: Wed, 16 Apr 2003 21:04:00 -0000 Message-Id: <200304162104.h3GL4rp01982@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Daniel Jacobowitz Cc: Elena Zannoni , gdb@sources.redhat.com Subject: Re: Linux kernel problem -- food for thoughts In-Reply-To: Daniel Jacobowitz's message of Wednesday, 16 April 2003 10:28:11 -0400 <20030416142811.GA9574@nevyn.them.org> X-Antipastobozoticataclysm: When George Bush projectile vomits antipasto on the Japanese. X-SW-Source: 2003-04/txt/msg00180.txt.bz2 > I was just thinking about this. My reaction is: > - the page needs to be readable; I vaguely remember badgering Linus > about this and getting it fixed, but it might have been someone else, > or it might not have gotten fixed. Or maybe you just got (or replicated) the half-assed patch I did for this, which only went to Linus yesterday. > - GDB needs to get the location of the EH information from glibc > somehow. My instinct is to make glibc export this in a global symbol, > just like the way we get signal numbers from linuxthreads. Bletch. libc isn't the source of the information. You could have a program that doesn't use glibc and since winds up at these PC locations. gdb should get the information from the kernel directly somehow. [Elena:] > Roland (but I'll let him speak) has had a thought about creating a > /proc/pid/vsyscall file, which then gdb could read with add-symbol-file.... I implemented this as a quick hack. I can send the 2.5 kernel patch to anyone who is interested. I am pretty sure this wouldn't get integrated into the kernel if I lobbied for it. Since the same address is used in every process (at least in all the kernels around now), it's also easy to use a little program (which I wrote first) to generate the file from the running kernel and then you can use that plain file with add-symbol-file. This is what I recommend we use for the first development step. That is, when the DWARF unwinding support for x86 is enabled generically, we can try the add-symbol-file trick (or an internal call kludged in) for the purposes of testing and debugging the unwinding, seeing the testsuite run happily with good backtraces, etc. It seems unlikely to be a good real implementation. For core files, I do think the only sensible thing will be to make the kernel write the vsyscall page into every core dump. Otherwise you can't always be sure when looking at a post-mortem exactly what the PC values it was using while alive meant at the time. For a live implementation not relying on a virtual ELF file, and for core files, there remains the issue of finding the .eh_frame start address. I have some thoughts, and that's a relatively minor detail to be worked out once the whole plan of using that info is agreed upon. Thanks, Roland