From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 96882 invoked by alias); 6 Dec 2017 10:28:33 -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 96577 invoked by uid 89); 6 Dec 2017 10:28:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 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 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; Wed, 06 Dec 2017 10:28:29 +0000 Received: from pps.filterd (m0098413.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vB6ANoxd046648 for ; Wed, 6 Dec 2017 05:28:27 -0500 Received: from e06smtp14.uk.ibm.com (e06smtp14.uk.ibm.com [195.75.94.110]) by mx0b-001b2d01.pphosted.com with ESMTP id 2epc8nfa4x-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 06 Dec 2017 05:28:27 -0500 Received: from localhost by e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 6 Dec 2017 10:28:26 -0000 Received: from b06cxnps3075.portsmouth.uk.ibm.com (9.149.109.195) by e06smtp14.uk.ibm.com (192.168.101.144) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 6 Dec 2017 10:28:24 -0000 Received: from d06av25.portsmouth.uk.ibm.com (d06av25.portsmouth.uk.ibm.com [9.149.105.61]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id vB6ASNU664094350; Wed, 6 Dec 2017 10:28:23 GMT Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 63A7E11C04C; Wed, 6 Dec 2017 10:22:50 +0000 (GMT) Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4F4CE11C04A; Wed, 6 Dec 2017 10:22:50 +0000 (GMT) Received: from oc3748833570.ibm.com (unknown [9.164.186.95]) by d06av25.portsmouth.uk.ibm.com (Postfix) with ESMTP; Wed, 6 Dec 2017 10:22:50 +0000 (GMT) Received: by oc3748833570.ibm.com (Postfix, from userid 1000) id 13EF7D80322; Wed, 6 Dec 2017 11:28:23 +0100 (CET) Subject: Re: [PATCH v2 01/11] s390: Remove duplicate checks for cached gdbarch@init To: prudo@linux.vnet.ibm.com (Philipp Rudo) Date: Wed, 06 Dec 2017 10:28:00 -0000 From: "Ulrich Weigand" Cc: qiyaoltc@gmail.com (Yao Qi), gdb-patches@sourceware.org, arnez@linux.vnet.ibm.com (Andreas Arnez) In-Reply-To: <20171206105613.0bab3345@ThinkPad> from "Philipp Rudo" at Dec 06, 2017 10:56:13 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 17120610-0016-0000-0000-00000509DD89 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17120610-0017-0000-0000-00002845DB4D Message-Id: <20171206102823.13EF7D80322@oc3748833570.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-12-06_04:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1712060152 X-SW-Source: 2017-12/txt/msg00119.txt.bz2 Philipp Rudo wrote: > On Tue, 05 Dec 2017 16:16:07 +0000 > Yao Qi wrote: > > Is it possible that we have two instances of gdbarch, with the same > > target description, but different vector_abi? Two different executables > > compiled with different vector abis, and GDB can debug them together > > (multi-process debugging. If we consider multi-target debugging in the > > future, these two executable can from different targets). > > For s390 there only is one vector abi (or non at all) at the time. If you were > debugging two different executables at the same time you would have two > inferiors each with its own gdbarch (same would be for multi-target debugging). > So I don't think those are the reasons. Actually, I think Yao is right here. As you say, we can have two executables, one using the vector ABI and one not. These will require two different gdbarch structures. But with the patch you propose, when trying to allocate the second of those two, GDB would see the first one that was already created earlier, and incorrectly assume that it can simply be reused. Basically, the problem is that there *can* be different gdbarchs that share the *same* tdesc, but differ in vector ABI. Therefore *only* checking for tdesc does not suffice to correctly identify cached gdbarch structures. I agree that it is redundant to again check differences (e.g. in register set) that would already have led to a different tdesc; but the vector ABI at least is not one of those. Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com