From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11811 invoked by alias); 6 Dec 2004 22:37:42 -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 11786 invoked from network); 6 Dec 2004 22:37:38 -0000 Received: from unknown (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org with SMTP; 6 Dec 2004 22:37:38 -0000 Received: from elgar.sibelius.xs4all.nl (elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.0/8.13.0) with ESMTP id iB6MbNRe023263; Mon, 6 Dec 2004 23:37:23 +0100 (CET) Received: from elgar.sibelius.xs4all.nl (localhost [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6) with ESMTP id iB6MbMmR000536; Mon, 6 Dec 2004 23:37:22 +0100 (CET) (envelope-from kettenis@elgar.sibelius.xs4all.nl) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6/Submit) id iB6MbIGY000533; Mon, 6 Dec 2004 23:37:18 +0100 (CET) Date: Mon, 06 Dec 2004 22:51:00 -0000 Message-Id: <200412062237.iB6MbIGY000533@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: kevinb@redhat.com CC: gdb-patches@sources.redhat.com In-reply-to: <20041206143109.7e29789f.kevinb@redhat.com> (message from Kevin Buettner on Mon, 6 Dec 2004 14:31:09 -0700) Subject: Re: [RFC] Generic support for qGetTLSAddr packet References: <20041206143109.7e29789f.kevinb@redhat.com> X-SW-Source: 2004-12/txt/msg00174.txt.bz2 Date: Mon, 6 Dec 2004 14:31:09 -0700 From: Kevin Buettner Since you asked for comments ;-): Yikes! That qGetTLSAddr in the function name is really ugly. That said, I don't understand why there's any need for the remote code to get so deep into the core GDB code. I don't see the big picture yet, but my initial reaction is that this must be wrong. Why does the remote protocol need to know more than a native GDB? The patch below implements support for the qGetTLSAddr packet. See: http://sources.redhat.com/ml/gdb/2004-11/msg00189.html This patch also adds a new gdbarch method for fetching the OS / ABI specific load module parameters. I don't think this should be added to the "glibal" gdbbarch vector. Instead, this probably should be architecture-dependent data that's only known to the remote protocol module. Mark