From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30424 invoked by alias); 17 Jun 2003 21:00:12 -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 30271 invoked from network); 17 Jun 2003 21:00:10 -0000 Received: from unknown (HELO palrel12.hp.com) (156.153.255.237) by sources.redhat.com with SMTP; 17 Jun 2003 21:00:10 -0000 Received: from hplms2.hpl.hp.com (hplms2.hpl.hp.com [15.0.152.33]) by palrel12.hp.com (Postfix) with ESMTP id B5F0F1C01177; Tue, 17 Jun 2003 14:00:06 -0700 (PDT) Received: from napali.hpl.hp.com (napali.hpl.hp.com [15.4.89.123]) by hplms2.hpl.hp.com (8.12.9/8.12.9/HPL-PA Hub) with ESMTP id h5HL05wH012813; Tue, 17 Jun 2003 14:00:06 -0700 (PDT) Received: from napali.hpl.hp.com (localhost [127.0.0.1]) by napali.hpl.hp.com (8.12.3/8.12.3/Debian-5) with ESMTP id h5HL05rK010437; Tue, 17 Jun 2003 14:00:05 -0700 Received: (from davidm@localhost) by napali.hpl.hp.com (8.12.3/8.12.3/Debian-5) id h5HL05pZ010433; Tue, 17 Jun 2003 14:00:05 -0700 From: David Mosberger MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16111.33109.103581.40103@napali.hpl.hp.com> Date: Tue, 17 Jun 2003 21:00:00 -0000 To: Roland McGrath Cc: davidm@hpl.hp.com, gdb@sources.redhat.com, binutils@sources.redhat.com Subject: Re: [davidm@napali.hpl.hp.com: readelf question] In-Reply-To: <200306172044.h5HKieb29320@magilla.sf.frob.com> References: <16111.30389.189801.925393@napali.hpl.hp.com> <200306172044.h5HKieb29320@magilla.sf.frob.com> Reply-To: davidm@hpl.hp.com X-URL: http://www.hpl.hp.com/personal/David_Mosberger/ X-SW-Source: 2003-06/txt/msg00356.txt.bz2 >>>>> On Tue, 17 Jun 2003 13:44:40 -0700, Roland McGrath said: Roland> The piece that still remains missing is gdb finding out Roland> where the DSO is, i.e. the AT_SYSINFO_EHDR value of a traced Roland> process. For that, I've proposed a new /proc/PID/auxv Roland> virtual file and a new NT_AUXV note in core dumps (these Roland> match exactly what Solaris provides). Sounds reasonable to me. Is /proc/PID/auxv really needed, though? Isn't it easy enough to get to the aux vector from the initial stack pointer (which gdb could catch from /proc/PID/stat). Roland> I posted a patch to implement this in Linux 2.5 to lkml on Roland> May 15; it was met with resounding silence. That may not mean much. Clearly it makes no sense to implement half a solution to the problem and given that the first half is in, I don't expect any issues in getting the rest (or some alternative) in. Andrew Morton is very good at collecting misc. patches, providing feedback, and feeding them on to Linus, so you might want to talk to him (please do cc me, too; I don't have much time to work on this myself, but I do want to make sure the ia64 portion stays in sync). --david