Re: [PATCH v2 01/11] s390: Remove duplicate checks for cached gdbarch@init

[Philipp Rudo <prudo at linux dot vnet dot ibm dot com>]

Hi Yao,

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!
Philipp


On Wed, 6 Dec 2017 11:28:23 +0100 (CET)
"Ulrich Weigand" <uweigand@de.ibm.com> wrote:

> Philipp Rudo wrote:
> 
> > On Tue, 05 Dec 2017 16:16:07 +0000
> > Yao Qi <qiyaoltc@gmail.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.
> 
> Bye,
> Ulrich
>