From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 129092 invoked by alias); 27 Jun 2018 13:12:49 -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 129083 invoked by uid 89); 27 Jun 2018 13:12:48 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0a-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.156.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 27 Jun 2018 13:12:47 +0000 Received: from pps.filterd (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w5RD9re1063235 for ; Wed, 27 Jun 2018 09:12:45 -0400 Received: from e06smtp01.uk.ibm.com (e06smtp01.uk.ibm.com [195.75.94.97]) by mx0a-001b2d01.pphosted.com with ESMTP id 2jv9ubc3yq-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 27 Jun 2018 09:12:44 -0400 Received: from localhost by e06smtp01.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 27 Jun 2018 14:12:42 +0100 Received: from b06cxnps3075.portsmouth.uk.ibm.com (9.149.109.195) by e06smtp01.uk.ibm.com (192.168.101.131) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Wed, 27 Jun 2018 14:12:40 +0100 Received: from d06av24.portsmouth.uk.ibm.com (d06av24.portsmouth.uk.ibm.com [9.149.105.60]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w5RDCdqb34472128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 27 Jun 2018 13:12:39 GMT Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 675A642042; Wed, 27 Jun 2018 14:12:31 +0100 (BST) Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 565594203F; Wed, 27 Jun 2018 14:12:31 +0100 (BST) Received: from oc3748833570.ibm.com (unknown [9.152.213.93]) by d06av24.portsmouth.uk.ibm.com (Postfix) with ESMTP; Wed, 27 Jun 2018 14:12:31 +0100 (BST) Received: by oc3748833570.ibm.com (Postfix, from userid 1000) id 5F0D5D801C0; Wed, 27 Jun 2018 15:12:39 +0200 (CEST) Subject: Re: [PATCH] Fix Cell debugging regression (Re: [PATCH] Use thread_info and inferior pointers more throughout) To: palves@redhat.com (Pedro Alves) Date: Wed, 27 Jun 2018 13:12:00 -0000 From: "Ulrich Weigand" Cc: tom@tromey.com (Tom Tromey), gdb-patches@sourceware.org In-Reply-To: from "Pedro Alves" at Jun 27, 2018 01:43:42 PM MIME-Version: 1.0 x-cbid: 18062713-4275-0000-0000-00000292789A X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18062713-4276-0000-0000-00003799E16A Message-Id: <20180627131239.5F0D5D801C0@oc3748833570.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-SW-Source: 2018-06/txt/msg00643.txt.bz2 Pedro Alves wrote: > > The change above switches the behavior to use the SPU architecture > > if GDB happens to interrupt SPU code. This is wrong and causes > > internal GDB errors pretty much instantly when starting an SPU ... > Sorry, missed that. Some comments here would be helpful. Agreed. :-) > gdb/ChangeLog: > 2018-06-27 Pedro Alves > > * proc-service.c (ps_lgetregs, ps_lsetregs, ps_lgetfpregs) > (ps_lsetfpregs): Use get_thread_main_regcache. > * regcache.c (get_thread_main_regcache): Define. > * regcache.h (get_thread_main_regcache): Declare. This looks good to me as far as the architecture is concerned. In the meantime I also noticed another potential issue (which is not related to multi-arch at all): > ps_err_e > ps_lgetregs (struct ps_prochandle *ph, lwpid_t lwpid, prgregset_t gregset) > { > - ptid_t ptid = ptid_build (ptid_get_pid (ph->ptid), lwpid, 0); > - struct regcache *regcache > - = get_thread_arch_regcache (ptid, target_gdbarch ()); > + struct regcache *regcache = get_thread_regcache (ph->thread); This change also assumes that ph->thread is the same thread as the one indicated by lwpid. Looking at the callers of the various libthread_db routines that might result in a callback to the ps_...regs routines, it is not immediately obvious to me that this is actually true. Are you sure this can never be called to look up registers of another thread? Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com