This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFC] remote.c: Add remote TLS support
- From: Daniel Jacobowitz <drow at false dot org>
- To: Kevin Buettner <kevinb at redhat dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Thu, 31 Mar 2005 18:45:07 -0500
- Subject: Re: [RFC] remote.c: Add remote TLS support
- References: <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