From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30675 invoked by alias); 1 Feb 2004 06:04:23 -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 30633 invoked from network); 1 Feb 2004 06:04:20 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 1 Feb 2004 06:04:20 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1AnAiR-0007Tz-63; Sun, 01 Feb 2004 01:04:19 -0500 Date: Sun, 01 Feb 2004 06:04:00 -0000 From: Daniel Jacobowitz To: Roland McGrath Cc: Andrew Cagney , gdb-patches@sources.redhat.com Subject: Re: [PATCH] auxv support Message-ID: <20040201060419.GA22586@nevyn.them.org> Mail-Followup-To: Roland McGrath , Andrew Cagney , gdb-patches@sources.redhat.com References: <200401310013.i0V0DnGE018646@magilla.sf.frob.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200401310013.i0V0DnGE018646@magilla.sf.frob.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-02/txt/msg00002.txt.bz2 On Fri, Jan 30, 2004 at 04:13:49PM -0800, Roland McGrath wrote: > For some reason I didn't get your message directly (yet anyway), though > I've now seen it in the mailing list archives. List reply bites again. If you are not subscribed to gdb-patches, please use a reply-to or something along those lines... otherwise I assume it was just mail lag. > As to the OPS argument to target_auxv_parse, I found it consistent and > originally had in mind that it would be used to know the wordsize and byte > order, since that seems like the appropriate sort of modularity to me. But > then I followed Andrew's code for the implementation, i.e. using > `extract_unsigned_integer' with its reference to global state. I presume > that what Andrew did is the current preferred thing to do. Frankly, I > can't figure out which parts of gdb's interface are supposed to be modular > in what way. Everything else related to this code uses target_ops pointers > instead of referring to global variables. I'm not sure whether the target is supposed to indicate an architecture in this fashion (target has-an architecture), but I guess it makes sense that (someday) it would. So, fine. You wrote elsewhere: >>The target vector update is fine. > > >Sorry, I'm not entirely clear on how to read you. Should I commit the >whole patch I posted now? (I'm not sure because you said "target vector >update", and my patch includes to_xfer_partial target updates, >to_make_corefile_notes target updates, and the `info auxv' user command.) I've approved the rest of the patch, so go ahead and check it in, along with the documentation. Then we can get back to the testcase and remote support. > + > + case TARGET_OBJECT_AUXV: > + sprintf (buf2, "qAuxVector:%lu", (unsigned long int) offset); > + i = putpkt (buf2); > + if (i < 0) > + return i; > + buf2[0] = '\0'; > + getpkt (buf2, rs->remote_packet_size, 0); > + if (buf2[0] == '\0') > + return -1; > + return hex2bin (buf2, readbuf, len); > + > default: > return -1; > } Seems reasonable. Probably the packet will need to be conditionally supported (see packet_ok, remote_P_packet or so). The mechanism for doing that at the moment involves a couple of copy/pastes, it needs cleaning up eventually. > A slightly more grandiose idea is to define it as: > > qAux::: > > This is in the target_read_partial vein, giving a string of auxv or > unwind or suchlike, and decimal values for and . > The reply packet should perhaps explicitly say whether it's just returning > a partial response, or if it read all there was, e.g. > > : > > I don't know if this is considered more or less desireable than an entirely > new flavor of packet for each kind of other-than-memory space to be accessed. Personally I would prefer a separate packet for each type of aux data. Gdbserver would end up with a strncmp (buf, "qAux:auxv", 9) versus a strncmp (buf, "qAuxVector:", 11), and qAuxVector is more straightforward to probe for the existence of. Perhaps it should be qAuxVector:: rather than qAuxVector:. Note that you'll need to use LinuxThreads (or no threads) if you want to test this with gdbserver; I have NPTL support almost done but it needs the remote.c patch I posted today. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer