From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18141 invoked by alias); 6 Dec 2017 09:56:24 -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 18127 invoked by uid 89); 6 Dec 2017 09:56:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no 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, 06 Dec 2017 09:56:22 +0000 Received: from pps.filterd (m0098393.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vB69tEAq017652 for ; Wed, 6 Dec 2017 04:56:21 -0500 Received: from e06smtp13.uk.ibm.com (e06smtp13.uk.ibm.com [195.75.94.109]) by mx0a-001b2d01.pphosted.com with ESMTP id 2epbnyy8ay-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 06 Dec 2017 04:56:20 -0500 Received: from localhost by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 6 Dec 2017 09:56:18 -0000 Received: from b06cxnps4075.portsmouth.uk.ibm.com (9.149.109.197) by e06smtp13.uk.ibm.com (192.168.101.143) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 6 Dec 2017 09:56:16 -0000 Received: from d06av23.portsmouth.uk.ibm.com (d06av23.portsmouth.uk.ibm.com [9.149.105.59]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id vB69uGu230998684; Wed, 6 Dec 2017 09:56:16 GMT Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 20C1EA404D; Wed, 6 Dec 2017 09:50:42 +0000 (GMT) Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E552BA4040; Wed, 6 Dec 2017 09:50:41 +0000 (GMT) Received: from ThinkPad (unknown [9.152.212.148]) by d06av23.portsmouth.uk.ibm.com (Postfix) with ESMTP; Wed, 6 Dec 2017 09:50:41 +0000 (GMT) Date: Wed, 06 Dec 2017 09:56:00 -0000 From: Philipp Rudo To: Yao Qi Cc: gdb-patches@sourceware.org, Andreas Arnez , Ulrich Weigand Subject: Re: [PATCH v2 01/11] s390: Remove duplicate checks for cached gdbarch at init In-Reply-To: <86wp21p2uw.fsf@gmail.com> References: <20171205122859.2919-1-prudo@linux.vnet.ibm.com> <20171205122859.2919-2-prudo@linux.vnet.ibm.com> <86wp21p2uw.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 17120609-0012-0000-0000-00000595DE72 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17120609-0013-0000-0000-00001910DEEB Message-Id: <20171206105613.0bab3345@ThinkPad> 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-1712060145 X-IsSubscribed: yes X-SW-Source: 2017-12/txt/msg00118.txt.bz2 Hi Yao, On Tue, 05 Dec 2017 16:16:07 +0000 Yao Qi wrote: > Philipp Rudo writes: > > > - /* Find a candidate among extant architectures. */ > > - for (arches = gdbarch_list_lookup_by_info (arches, &info); > > - arches != NULL; > > - arches = gdbarch_list_lookup_by_info (arches->next, &info)) > > - { > > - tdep = gdbarch_tdep (arches->gdbarch); > > - if (!tdep) > > - continue; > > - if (tdep->abi != tdep_abi) > > - continue; > > - if (tdep->vector_abi != vector_abi) > > - continue; > > 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. For me it more looks like a mix of copy&paste code combined with an improper clean up when the gdbarch_info->tdesc field was introduced. This pattern was introduced in 2000 (7a78ae4e6b0) for ppc/rs6k (in rs6000-tdep.c) and copy&pasted to s390 in 2010 (7803799a0fb). Between the two commits in 2006 (424163ea152) the tdesc field (with the corresponding check) was added to gdbarch_info without cleaning up the uses of gdbarch_list_lookup_by_info. Unfortunately none of the commits have a commit message and the ChangeLog isn't very helpful... Thanks Philipp > > - if ((tdep->gpr_full_regnum != -1) != have_upper) > > - continue; > > - if (tdep->have_gs != have_gs) > > - continue; > > - if (tdesc_data != NULL) > > - tdesc_data_cleanup (tdesc_data); > > - return arches->gdbarch; > > - } >