From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 128370 invoked by alias); 5 Dec 2017 16:16:22 -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 128355 invoked by uid 89); 5 Dec 2017 16:16:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*r:sk:static., among X-HELO: mail-wm0-f53.google.com Received: from mail-wm0-f53.google.com (HELO mail-wm0-f53.google.com) (74.125.82.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 05 Dec 2017 16:16:15 +0000 Received: by mail-wm0-f53.google.com with SMTP id f206so2247909wmf.5 for ; Tue, 05 Dec 2017 08:16:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=G08TIebOsMw+sQr8EtmCYcjEg9vC4sn8b7aZ5LvHLhE=; b=i5Ff8kerZbL9A2n5IFPdbTyMbaCV/4tBeeyDbAOuwmb2bdJU0z2Djfz1461yQR7GqT 2tJ2zJMgcKRomk60gdvXf/yQrUFWxOey9ULaRdkM+x3/oA72xow1LK2oIktJq/aUh9Uq QFWgLIETXFfZ8akgiYbPO80JWlnF5Ge+9TFqHt+2fQzmIulq+xNlAwpzuUQC+DUO6n0J Shxuvycvdga4igBk1ypVVnFjYbgM1n8D+C6wTh0EPqT6KrMInuq2IkqhqJPhyPE22FkU ZZsq5f9/nmjPXHOgw/gGo9jDFElaOYJN4XQoVxzem+CnnB2SqLh0pNhzy48ircgR2Kuf bgBg== X-Gm-Message-State: AKGB3mLyWvxcK2yLEDJifylLpmb4c2idyGjWC+FsrsM2TRTHSVlKLJ8/ YHbHX0Ux7y/ktZZ1oOrAibE= X-Google-Smtp-Source: AGs4zMYNwfvYEp/3kGnVpuJO2KttnlNYwABkFmjptnEnh8jHR4ki9DUhXv+h61KgYm320tDDDDiWYQ== X-Received: by 10.28.247.15 with SMTP id v15mr5915063wmh.152.1512490573578; Tue, 05 Dec 2017 08:16:13 -0800 (PST) Received: from E107787-LIN (static.42.136.251.148.clients.your-server.de. [148.251.136.42]) by smtp.gmail.com with ESMTPSA id p72sm708839wme.17.2017.12.05.08.16.11 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Tue, 05 Dec 2017 08:16:12 -0800 (PST) From: Yao Qi To: Philipp Rudo Cc: gdb-patches@sourceware.org, Andreas Arnez , Ulrich Weigand Subject: Re: [PATCH v2 01/11] s390: Remove duplicate checks for cached gdbarch at init References: <20171205122859.2919-1-prudo@linux.vnet.ibm.com> <20171205122859.2919-2-prudo@linux.vnet.ibm.com> Date: Tue, 05 Dec 2017 16:16:00 -0000 In-Reply-To: <20171205122859.2919-2-prudo@linux.vnet.ibm.com> (Philipp Rudo's message of "Tue, 5 Dec 2017 13:28:49 +0100") Message-ID: <86wp21p2uw.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-12/txt/msg00107.txt.bz2 Philipp Rudo writes: > - /* Find a candidate among extant architectures. */ > - for (arches =3D gdbarch_list_lookup_by_info (arches, &info); > - arches !=3D NULL; > - arches =3D gdbarch_list_lookup_by_info (arches->next, &info)) > - { > - tdep =3D gdbarch_tdep (arches->gdbarch); > - if (!tdep) > - continue; > - if (tdep->abi !=3D tdep_abi) > - continue; > - if (tdep->vector_abi !=3D 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). > - if ((tdep->gpr_full_regnum !=3D -1) !=3D have_upper) > - continue; > - if (tdep->have_gs !=3D have_gs) > - continue; > - if (tdesc_data !=3D NULL) > - tdesc_data_cleanup (tdesc_data); > - return arches->gdbarch; > - } --=20 Yao (=E9=BD=90=E5=B0=A7)