From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6988 invoked by alias); 6 Oct 2003 19:31:44 -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 6954 invoked from network); 6 Oct 2003 19:31:43 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 6 Oct 2003 19:31:43 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h96JVh109586 for ; Mon, 6 Oct 2003 15:31:43 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h96JVgc17519 for ; Mon, 6 Oct 2003 15:31:42 -0400 Received: from localhost.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id h96JVfbe006489; Mon, 6 Oct 2003 15:31:42 -0400 Received: by localhost.redhat.com (Postfix, from userid 469) id A3C7C2CC88; Mon, 6 Oct 2003 15:42:28 -0400 (EDT) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16257.50596.85774.226265@localhost.redhat.com> Date: Mon, 06 Oct 2003 19:31:00 -0000 To: Roland McGrath Cc: gdb-patches@sources.redhat.com Subject: Re: unwind support for Linux 2.6 vsyscall DSO In-Reply-To: <200310030827.h938RsrS019019@magilla.sf.frob.com> References: <200310030827.h938RsrS019019@magilla.sf.frob.com> X-SW-Source: 2003-10/txt/msg00114.txt.bz2 Roland McGrath writes: > In the past (during this spring and summer) there were some discussions > about the need to find unwind info in the vsyscall DSO image implicitly > loaded in processes on Linux 2.5/2.6 on some platforms. I honestly don't > recall which mailing lists this was on. If people are not clear on the > issues, I can try to dig up the various summaries of the details I have > posted before. This was tabled for a while when I had other priorities > since it didn't turn out to be an issue with any kernel version used by > Red Hat production systems. > > Now Linux 2.6 is getting firmed up, and it's time to revisit this. On > Linux 2.6 kernels, backtraces from programs stopped in system calls do not > work using current glibc on x86 and AMD64 machines. The same issue exists > on IA64 in Linux 2.6, and glibc will before long make use of the feature so > that system call backtraces need the same solutions for IA64. > > My changes to export the auxv information in core dumps and /proc are now > making their way into Linux 2.6, and this gives us the tools we need to > solve the problem in gdb. Ok, reading the thread, I see that you are running pretty much into the same problems I am running into for PIE support. What kind of information is exacty exported into the auxv file? I am wondering if you also have the entry point of the program there (AT_ENTRY, looking at the Solaris auxv.h), because if so it may change my current way of looking at PIE, where I am taking the info from the /proc/pid/map file, which is not saved in the core file, I think, while auxv is. Anyway, this issue aside, there is a target method in gdb to process the various entries in the map file. I think it would be appropriate to translate that into something similar for reading the auxv file. Have a look at target_find_memory_regions. It is defined for linux in linux-proc.c, and for Solaris in procfs.c, and for fbsd as well. It is just an iterator over the entries in the map file, but you get the general idea. There is a bug in there as it is not defined properly for the core target, while in this case it obviously should be. This way it could be easily extended for Solaris, etc too, some day. For the core file case, look at gcore.c:objfile_find_memory_regions(). This is the one that fiddles with remote/core cases. You are in an analogous situation here with reading from bfd instead of /proc. Of course, the target_find_memory_regions() function is called only by the gcore command, which is quite different from what you need to do. I agree that treating this new information as much as possible as a shared library will make our life easier, because all the checks are done in the right spots already. I have some solib debug code that Kevin approved for mainline, I'll commit it now, if that can be of help in seeing what happens when shlibs are loaded. elena