Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: Kevin Buettner <kevinb@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFC] remote.c: Add remote TLS support
Date: Thu, 31 Mar 2005 23:43:00 -0000	[thread overview]
Message-ID: <20050331234507.GA14974@nevyn.them.org> (raw)
In-Reply-To: <20050331162017.0e47552c@ironwood.lan>

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


  reply	other threads:[~2005-03-31 23:43 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-31 23:20 Kevin Buettner
2005-03-31 23:43 ` Daniel Jacobowitz [this message]
2005-04-15 20:09 ` Kevin Buettner
2005-04-15 20:12   ` Daniel Jacobowitz
2005-04-15 20:30     ` Kevin Buettner
2005-04-15 21:02     ` Kevin Buettner
2005-04-16  9:14   ` Eli Zaretskii
2005-04-22 13:14   ` Eli Zaretskii
2005-04-26 23:39     ` Kevin Buettner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050331234507.GA14974@nevyn.them.org \
    --to=drow@false.org \
    --cc=gdb-patches@sources.redhat.com \
    --cc=kevinb@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox