[PATCH v2 01/11] s390: Remove duplicate checks for cached gdbarch@init
Thu Dec 7 09:18:00 GMT 2017
I quickly talked to Uli yesterday about this and you and Uli are right. There
is a possibility that a program chooses not to use the vector registers for
their abi even when they are present. I fixed the patch locally.
Thanks for catching this!
On Wed, 6 Dec 2017 11:28:23 +0100 (CET)
"Ulrich Weigand" <firstname.lastname@example.org> wrote:
> Philipp Rudo wrote:
> > On Tue, 05 Dec 2017 16:16:07 +0000
> > Yao Qi <email@example.com> 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.
More information about the Gdb-patches