From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24242 invoked by alias); 17 Jun 2003 20:44:48 -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 24173 invoked from network); 17 Jun 2003 20:44:46 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.163.213.212) by sources.redhat.com with SMTP; 17 Jun 2003 20:44:46 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 904D2354C; Tue, 17 Jun 2003 13:44:45 -0700 (PDT) Received: (from roland@localhost) by magilla.sf.frob.com (8.11.6/8.11.6) id h5HKieb29320; Tue, 17 Jun 2003 13:44:40 -0700 Date: Tue, 17 Jun 2003 20:44:00 -0000 Message-Id: <200306172044.h5HKieb29320@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: davidm@hpl.hp.com Cc: gdb@sources.redhat.com, binutils@sources.redhat.com Subject: Re: [davidm@napali.hpl.hp.com: readelf question] In-Reply-To: David Mosberger's message of Tuesday, 17 June 2003 13:14:45 -0700 <16111.30389.189801.925393@napali.hpl.hp.com> X-Shopping-List: (1) Botanical squirrels (2) Mrs. Leland's Party rodents (3) Fastidious shrubbery (4) Philanthropic thunder X-SW-Source: 2003-06/txt/msg00354.txt.bz2 > Andrew> Last I heard was a kernel patch to make auxv info available > Andrew> in the core file, and via the /proc and ptrace interfaces. > > Yes: auxv, core, and ptrace are there. I don't think /proc support is > there. Not sure if Roland is planning to do something about that. To clarify, I think what David's saying (and what I think is the case) is that access to these memory regions via core dumps and ptrace does work just like any other user address, and that the startup-time aux vector on a process's stack contains AT_SYSINFO_EHDR to tell the process the location. The piece that still remains missing is gdb finding out where the DSO is, i.e. the AT_SYSINFO_EHDR value of a traced process. For that, I've proposed a new /proc/PID/auxv virtual file and a new NT_AUXV note in core dumps (these match exactly what Solaris provides). I posted a patch to implement this in Linux 2.5 to lkml on May 15; it was met with resounding silence. Pushing that patch has not been top priority since then, since this issue affects gdb only with 2.5 kernels and so is not an imminent concern for the Red Hat products I work on. After posting that patch, I realized it had a leak. I didn't bother to follow up with the corrected patch immediately, since my posting of the first patch had failed to solicit any response of any kind even on the question of the interface. I would be happy to dust off that patch and send it to you, post it again, or send it anywhere else that would increase the likelihood of getting some response about it. If Linux kernel folks are happy enough with the interface but not with the implementation, I would be glad to rewrite it as requested. > Andrew> Thing is, if that's done, those extra memory sections can go > Andrew> back to being extra memory sections (and everything becomes > Andrew> much simpler). I don't really understand what this comment means from its content. The special page(s) the kernel provides for the vsyscall/gate DSO are already normal regions of memory as far as access via ptrace, /proc, and ocre dumps is concerned. I can guess from Andrew's past comments that he is in fact talking about the auxv access feature, and trying to say that he believes having that simplifies the interpretation of core files as opposed to using the core files' new phdrs for that (something that is in fact trivial and I've already implemented). In prior discussion, it was the clear conclusion that gdb hackers' highest preference is for the /proc/PID/auxv+NT_AUXV kernel interface being added. I have repeatedly made clear that I am happy to implement whatever combination of things jibes best with the preferences of Linux kernel hackers and gdb hackers. So far we have no input whatosever on what the preferences from the kernel side might be. > I don't have much of a preference myself. I'm sure Roland has thought > much more about the user-level parts of the support than I have > (though I do like the idea of being able to get symbol and library > info for the kernel DSO(s); not sure how you'd do that with plain > memory sections). We have discussed it in great detail on the gdb list. Check the archives. Thanks, Roland