From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8060 invoked by alias); 31 Mar 2005 23:43:56 -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 7830 invoked from network); 31 Mar 2005 23:43:48 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 31 Mar 2005 23:43:48 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50 #1 (Debian)) id 1DH9LX-0003w4-Q0; Thu, 31 Mar 2005 18:45:07 -0500 Date: Thu, 31 Mar 2005 23:43:00 -0000 From: Daniel Jacobowitz To: Kevin Buettner Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC] remote.c: Add remote TLS support Message-ID: <20050331234507.GA14974@nevyn.them.org> Mail-Followup-To: Kevin Buettner , gdb-patches@sources.redhat.com References: <20050331162017.0e47552c@ironwood.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050331162017.0e47552c@ironwood.lan> User-Agent: Mutt/1.5.6+20040907i X-SW-Source: 2005-03/txt/msg00400.txt.bz2 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