From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9087 invoked by alias); 30 Jan 2004 19:03:59 -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 9078 invoked from network); 30 Jan 2004 19:03:58 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 30 Jan 2004 19:03:58 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1Amdvq-00052W-0n for ; Fri, 30 Jan 2004 14:03:58 -0500 Date: Fri, 30 Jan 2004 19:03:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: [PATCH] auxv support Message-ID: <20040130190357.GA18536@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <200401290259.i0T2x1c6001143@magilla.sf.frob.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200401290259.i0T2x1c6001143@magilla.sf.frob.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-01/txt/msg00763.txt.bz2 On Wed, Jan 28, 2004 at 06:59:01PM -0800, Roland McGrath wrote: > Ok, I think this is looking pretty polished now. I've tested it on Linux > and Solaris. On both systems I tested the live process case, the core file > case, and gcore. I did not test a multithreaded Solaris program, so that > trivial part of the code path has not actually been exercised. > > This adds the underlying support we talked about before, implemented > basically the same as my earlier patch. It also adds the `info auxv' > command as Andrew proposed, but with slightly nicer output. The function > for reading /proc/PID/auxv, and some of the other code previously > duplicated between the procfs and linux implementations, is now shared code > in auxv.c. There is also a utility function there that is what's needed > for finding a single known tag's value, as some hook will do to check for > AT_SYSINFO_EHDR. I've reviewed this patch. I think that it's OK, although I have one comment: > +int > +target_auxv_parse (struct target_ops *ops, char **readptr, char *endptr, > + CORE_ADDR *typep, CORE_ADDR *valp) I don't see any point in having OPS here, and it's neither used nor described in the comment. Since Andrew submitted a previous patch for the same feature, I'd appreciate it if he would look over this also. > I would like to add remote protocol and gdbserver support as well, but > someone knowledgeable about gdbserver should ping me. Andrew's the remote protocol guru, and I handle gdbserver; feel free to ask anything. I imagine that adding a utility function somewhere to read /proc/%d/auxv and a dispatch point in the target_ops structure is all that it would take. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer