From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32141 invoked by alias); 17 Jun 2003 21:15:38 -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 32041 invoked from network); 17 Jun 2003 21:15:32 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.131) by sources.redhat.com with SMTP; 17 Jun 2003 21:15:32 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 396862B5F; Tue, 17 Jun 2003 17:15:30 -0400 (EDT) Message-ID: <3EEF84F2.2010201@redhat.com> Date: Tue, 17 Jun 2003 21:15:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: davidm@hpl.hp.com Cc: Roland McGrath , gdb@sources.redhat.com, binutils@sources.redhat.com Subject: Re: [davidm@napali.hpl.hp.com: readelf question] References: <16111.30389.189801.925393@napali.hpl.hp.com> <200306172044.h5HKieb29320@magilla.sf.frob.com> <16111.33109.103581.40103@napali.hpl.hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-06/txt/msg00359.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). The inital stack, like anything else, can be corrupted. GDB's asking for a definitive source. This raised in the original thread. > 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). Roland, yes, I'm suggesting that only simple loadN sections be created - would simplify the core dump code. Andrew