From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9346 invoked by alias); 19 May 2017 15:24:40 -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 9095 invoked by uid 89); 19 May 2017 15:24:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=Heavy, cents, speak, investigating X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0b-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.158.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 19 May 2017 15:24:19 +0000 Received: from pps.filterd (m0098414.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v4JFLvYs007925 for ; Fri, 19 May 2017 11:24:18 -0400 Received: from e06smtp10.uk.ibm.com (e06smtp10.uk.ibm.com [195.75.94.106]) by mx0b-001b2d01.pphosted.com with ESMTP id 2aj39h82ww-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Fri, 19 May 2017 11:24:17 -0400 Received: from localhost by e06smtp10.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 19 May 2017 16:24:16 +0100 Received: from b06cxnps3075.portsmouth.uk.ibm.com (9.149.109.195) by e06smtp10.uk.ibm.com (192.168.101.140) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 19 May 2017 16:24:12 +0100 Received: from d06av26.portsmouth.uk.ibm.com (d06av26.portsmouth.uk.ibm.com [9.149.105.62]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id v4JFOCOb11338158; Fri, 19 May 2017 15:24:12 GMT Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C3140AE057; Fri, 19 May 2017 16:22:17 +0100 (BST) Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9793DAE053; Fri, 19 May 2017 16:22:17 +0100 (BST) Received: from oc1027705133.ibm.com (unknown [9.152.212.109]) by d06av26.portsmouth.uk.ibm.com (Postfix) with ESMTPS; Fri, 19 May 2017 16:22:17 +0100 (BST) From: Andreas Arnez To: Yao Qi Cc: Philipp Rudo , Omair Javaid , "gdb-patches\@sourceware.org" , Yao Qi , Peter Griffin Subject: Re: [RFC v3 3/8] Add basic Linux kernel support References: <20170316165739.88524-1-prudo@linux.vnet.ibm.com> <20170316165739.88524-4-prudo@linux.vnet.ibm.com> <86d1br8q8v.fsf@gmail.com> <20170503173626.15e61941@ThinkPad> <20170508132204.7a733dc2@ThinkPad> <86d1b5z142.fsf@gmail.com> Date: Fri, 19 May 2017 15:24:00 -0000 In-Reply-To: <86d1b5z142.fsf@gmail.com> (Yao Qi's message of "Fri, 19 May 2017 09:45:17 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-TM-AS-GCONF: 00 x-cbid: 17051915-0040-0000-0000-000003916E05 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17051915-0041-0000-0000-0000257349B7 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-05-19_09:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705190095 X-IsSubscribed: yes X-SW-Source: 2017-05/txt/msg00452.txt.bz2 On Fri, May 19 2017, Yao Qi wrote: > Philipp Rudo writes: > >> * Implement separate thread_lists. >> Allow every target to manage its own thread_list. Heavy impact for you and a >> lot work for me... > > Hi Philipp, > before you spend a lot of time implementing this, it is better to start > an RFC discussion on an appropriate time, so that people can well > understand why do we need this change. FYI, I have just started investigating this a bit. The reason for multiple thread lists has been covered in some of the discussions already, but let me give my few cents. In the kernel live debug scenario we conceptually have two different thread models layered on top of each other: * LK target: Thread == Linux kernel thread * Remote target: Thread == CPU If we represent CPUs and Linux threads in a single thread list, then it becomes difficult to maintain consistency between the LK target and the remote target: Who owns which parts of the thread_info? How to guarantee unique ptids across the board, etc.? Not to speak of the confusing "info threads" output if CPUs and threads are munged together. Unfortunately many places in GDB assume that there is just one thread list, one active target and one current inferior/thread. In order to maintain multiple thread lists cleanly, we probably have to lift these restrictions and get rid of the global variables current_target, thread_list, inferior_ptid, etc., or most of their uses. That's my preliminary conclusion, anyway. Alternate suggestions are welcome. -- Andreas