From: Philipp Rudo <prudo@linux.vnet.ibm.com>
To: Yao Qi <qiyaoltc@gmail.com>
Cc: gdb-patches@sourceware.org,
Andreas Arnez <arnez@linux.vnet.ibm.com>,
Ulrich Weigand <uweigand@de.ibm.com>
Subject: Re: [PATCH v2 01/11] s390: Remove duplicate checks for cached gdbarch at init
Date: Wed, 06 Dec 2017 09:56:00 -0000 [thread overview]
Message-ID: <20171206105613.0bab3345@ThinkPad> (raw)
In-Reply-To: <86wp21p2uw.fsf@gmail.com>
Hi Yao,
On Tue, 05 Dec 2017 16:16:07 +0000
Yao Qi <qiyaoltc@gmail.com> wrote:
> Philipp Rudo <prudo@linux.vnet.ibm.com> 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;
> > - }
>
next prev parent reply other threads:[~2017-12-06 9:56 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-05 12:29 [PATCH v2 00/11] Split up s390-linux-tdep.c Philipp Rudo
2017-12-05 12:29 ` [PATCH v2 06/11] s390: if -> gdb_assert for tdesc_has_registers check Philipp Rudo
2017-12-05 12:29 ` [PATCH v2 01/11] s390: Remove duplicate checks for cached gdbarch at init Philipp Rudo
2017-12-05 16:16 ` Yao Qi
2017-12-06 9:56 ` Philipp Rudo [this message]
2017-12-06 10:28 ` [PATCH v2 01/11] s390: Remove duplicate checks for cached gdbarch@init Ulrich Weigand
2017-12-07 9:18 ` Philipp Rudo
2017-12-07 9:59 ` Yao Qi
2017-12-05 12:29 ` [PATCH v2 03/11] s390: gdbarch_tdep.have_* int -> bool Philipp Rudo
2017-12-05 12:29 ` [PATCH v2 07/11] s390: Hook s390 into OSABI mechanism Philipp Rudo
2017-12-05 13:21 ` Ulrich Weigand
2017-12-05 17:06 ` Philipp Rudo
2017-12-05 17:44 ` Ulrich Weigand
2017-12-06 11:39 ` Philipp Rudo
2017-12-05 12:29 ` [PATCH v2 11/11] s390: Add comments to uncommented functions in s390-linux-tdep.c Philipp Rudo
2017-12-05 12:29 ` [PATCH v2 10/11] s390: Add comments to uncommented functions in s390-tdep.c Philipp Rudo
2017-12-05 12:29 ` [PATCH v2 05/11] s390: Move tdesc validation to separate function Philipp Rudo
2017-12-05 12:29 ` [PATCH v2 09/11] s390: Clean up s390-linux-tdep.c Philipp Rudo
2017-12-05 12:29 ` [PATCH v2 04/11] s390: gdbarch_tdep add field tdesc Philipp Rudo
2017-12-05 12:29 ` [PATCH v2 02/11] s390: Allocate gdbarch & tdep at start of gdbarch init Philipp Rudo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171206105613.0bab3345@ThinkPad \
--to=prudo@linux.vnet.ibm.com \
--cc=arnez@linux.vnet.ibm.com \
--cc=gdb-patches@sourceware.org \
--cc=qiyaoltc@gmail.com \
--cc=uweigand@de.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox