From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7842 invoked by alias); 9 Apr 2017 05:50:06 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 7757 invoked by uid 89); 9 Apr 2017 05:50:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=representations, pthreads, H*r:sk:201-226, H*r:vM.8.01.05 X-HELO: fed1rmfepo102.cox.net Received: from fed1rmfepo102.cox.net (HELO fed1rmfepo102.cox.net) (68.230.241.144) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 09 Apr 2017 05:50:01 +0000 Received: from fed1rmimpo109.cox.net ([68.230.241.158]) by fed1rmfepo102.cox.net (InterMail vM.8.01.05.28 201-2260-151-171-20160122) with ESMTP id <20170409055001.DER32620.fed1rmfepo102.cox.net@fed1rmimpo109.cox.net> for ; Sun, 9 Apr 2017 01:50:01 -0400 Received: from pinnacle.lan ([70.176.31.165]) by fed1rmimpo109.cox.net with cox id 65q01v00C3ZlYcN015q0PJ; Sun, 09 Apr 2017 01:50:01 -0400 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-Spam: 0 X-Authority-Analysis: v=2.1 cv=etp/ttdX c=1 sm=1 tr=0 a=ZvOrSFgHO2d7oiPvmX5V7g==:117 a=ZvOrSFgHO2d7oiPvmX5V7g==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=oyut9GbbctCLMBOnkGoA:9 a=CjuIK1q_8ugA:10 X-CM-Score: 0.00 Authentication-Results: cox.net; auth=pass (LOGIN) smtp.auth=buettner2@cox.net Date: Sun, 09 Apr 2017 05:50:00 -0000 From: Kevin Buettner To: gdb-patches@sourceware.org Subject: [PATCH v2 0/7] Thread handle to thread info mapping Message-ID: <20170408224959.67164a27@pinnacle.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2017-04/txt/msg00209.txt.bz2 This patch set introduces support for mapping thread handles to the thread_info structs which GDB uses to keep track of threads in the inferiors which it's debugging. I need this in order to find the GDB thread which corresponds to a saved thread handle (e.g. pthread_t) within an implementation of a thread library built atop pthreads. The mechanism is general enough however to support other thread handle representations as well. Part 1 introduces a target method which maps a thread handle to the corresponding internal GDB thread object, i.e. something of type `struct thread_info *'. An implementation of this new method is provided for the Linux thread target. Additional work will be required, over time, for other thread targets. Part 2 adds a python interface for the mechanism introduced in part 1. Part 3 is a documentation patch. It has been adjusted to address Eli's concerns in the earlier patch series. Part 4 adds a test case. I've extended this test case slightly from the patch in the earlier series. Part 5 is a bug fix for a problem discovered while working on part 6. Part 6 adds support for remote targets. Part 7 is a documentation patch for the remote protocol changes that were implemented in part 6.