From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17349 invoked by alias); 21 Jan 2004 22:13:56 -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 17335 invoked from network); 21 Jan 2004 22:13:55 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 21 Jan 2004 22:13:55 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1AjQbh-00038P-OB; Wed, 21 Jan 2004 17:13:53 -0500 Date: Wed, 21 Jan 2004 22:13:00 -0000 From: Daniel Jacobowitz To: Roland McGrath Cc: Andrew Cagney , gdb-patches@sources.redhat.com Subject: Re: [PATCH] auxv support via xfer_partial, for core files and /proc Message-ID: <20040121221353.GA3324@nevyn.them.org> Mail-Followup-To: Roland McGrath , Andrew Cagney , gdb-patches@sources.redhat.com References: <400E9F30.1060106@gnu.org> <200401212206.i0LM6gP1025948@magilla.sf.frob.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200401212206.i0LM6gP1025948@magilla.sf.frob.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-01/txt/msg00596.txt.bz2 On Wed, Jan 21, 2004 at 02:06:42PM -0800, Roland McGrath wrote: > > Roland, FYI, there is already this patch: > > http://sources.redhat.com/ml/gdb-patches/2003-11/msg00204.html > > Thanks for the pointer. I have some comments below comparing the two patches. > > > What you should definitly do is add yourself to the write-after-approval > > list (don't forget to the ChangeLog and to post the committed change). > > Done. > > > Here are the notable differences between the two patches. > > > 1. My patch includes the changes affecting gcore: > > * procfs.c (procfs_make_note_section): If we can read > TARGET_OBJECT_AUXV data, add an NT_AUXV note containing it. > * linux-proc.c (linux_make_note_section): Likewise. > > This is not something your patch tries to address. I think we want those > changes regardless of the implementation details for TARGET_OBJECT_AUXV. This could be an independent patch, couldn't it? In the interest of progress, you may wish to submit it separately. Of course it would have to come after rather than before... so maybe not. > 5. Your implementation uses pread unconditionally. Mine doesn't bother to > use pread even when it's available, and just uses lseek + read. Full > portability, including things like older glibcs running on newer > kernels, requires using configure tests for pread. I did not bother > with that because in the real-world case, there will just be one read > from offset 0 and so lseek won't even be called, just open+read+close. The configury is already there, FYI. Grep for HAVE_PREAD64 in linux-proc.c. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer