This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] remote.c: Add remote TLS support


On Thu, Mar 31, 2005 at 04:20:17PM -0700, Kevin Buettner wrote:
>     1) Allow this patch in even though it calls a deprecated function.
> 
>     2) Convert the other functions that currently call
>        deprecated_show_value_hack() to use some other mechanism.  Then,
>        resubmit this patch so that the new show_... function introduced
>        in this patch uses the new machinery.
> 
> Opinions?  If (2) is the preferred route, could someone outline how
> the conversion to not use deprecated_show_value_hack() ought to be done?

These functions have been on my hit list for a long time.  I don't
suppose I could persuade you to do this instead?

     3) Unify the six places that have to be modified to add a new
        configurable remote packet.

If not, 2) is the way to go, because it's so easy in this case.  The
conversion for deprecated_show_value_hack is simple.  Take a look at
the ARM patch I posted yesterday, which converted "set arm fpu"; all
that function does is print out a formatted message saying what the
value of the variable is.  Replace it with an appropriate printf.

> +/* Get the address of the thread local variable in OBJFILE which is
> +   stored at OFFSET within the thread local storage for thread PTID.  */
> +
> +static CORE_ADDR
> +remote_get_thread_local_address (ptid_t ptid, CORE_ADDR lm, CORE_ADDR offset)
> +{
> +  if (remote_protocol_qGetTLSAddr.support != PACKET_DISABLE)
> +    {
> +      struct remote_state *rs = get_remote_state ();
> +      char *buf = alloca (rs->remote_packet_size);
> +      char *p = buf;
> +      int status, argcnt;
> +      ULONGEST *extra_args;
> +
> +      strcpy (p, "qGetTLSAddr:");
> +      p += strlen (p);
> +      p += hexnumstr (p, PIDGET (ptid));
> +      *p++ = ',';
> +      p += hexnumstr (p, offset);
> +      *p++ = ',';
> +      p += hexnumstr (p, lm);
> +      *p++ = '\0';
> +
> +      putpkt (buf);
> +      getpkt (buf, rs->remote_packet_size, 0);
> +      if (packet_ok (buf, &remote_protocol_qGetTLSAddr) == PACKET_OK)
> +	{
> +	  ULONGEST result;
> +
> +	  unpack_varlen_hex (buf, &result);
> +	  return result;
> +	}
> +      else
> +	{
> +	  struct exception e
> +	    = { RETURN_ERROR, TLS_GENERIC_ERROR,
> +		"Remote target failed to process qGetTLSAddr request" };
> +	  throw_exception (e);
> +
> +	}

Won't this exception be thrown if the target doesn't support the
operation at all? The first time through the loop we will try to
auto-sense the packet and this is what will happen if the response is
"".

-- 
Daniel Jacobowitz
CodeSourcery, LLC


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]