Re: [PATCH] auxv support

[Daniel Jacobowitz <drow at mvista dot com>]

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:<what>:<offset>:<readsize>
> 
> This is in the target_read_partial vein, giving a <what> string of auxv or
> unwind or suchlike, and decimal values for <offset> and <readsize>.
> The reply packet should perhaps explicitly say whether it's just returning
> a partial response, or if it read all there was, e.g.
> 
> 	<totalsize>:<hexdata>
> 
> 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:<offset>:<readsize> rather than qAuxVector:<offset>.

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