Re: [PATCH v11 9/9] xen: explicit casts when DECLARE_BOUNDS cannot be used [and 1 more messages] [and 1 more messages]

From: Ian Jackson <ian.jackson@citrix.com>
To: Jan Beulich <jbeulich@suse.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Cc: Stefano Stabellini <stefanos@xilinx.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"julien.grall@arm.com" <julien.grall@arm.com>,
	George Dunlap <George.Dunlap@citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>
Subject: Re: [PATCH v11 9/9] xen: explicit casts when DECLARE_BOUNDS cannot be used [and 1 more messages] [and 1 more messages]
Date: Fri, 8 Mar 2019 15:39:45 +0000	[thread overview]
Message-ID: <23682.36033.541097.178160@mariner.uk.xensource.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1903071451180.17248@sstabellini-ThinkPad-X260>, <5C8227AD020000780015016A@prv1-mh.provo.novell.com>

Jan Beulich writes ("Re: [PATCH v11 9/9] xen: explicit casts when DECLARE_BOUNDS cannot be used [and 1 more messages]"):
> Ian Jackson <ian.jackson@citrix.com> 03/07/19 4:26 PM >>>
> >Jan, I'm not sure exactly what you are suggesting.  Currently the
> >array has one pointer per element.  Are you suggesting it should have
> >two pointers (start and end), with different notional types ?
> 
> Yes.

Right.

> >If that is OK from a perf point of view then it is an easy answer
> >(although a bit tiresome since more linker symbols will have to be
> >generated).
> 
> This is init-time code and init-time data, so to me neither the performance
> aspect nor the doubled storage requirements would really matter.

Jolly good.

> Both could perhaps even be eliminated by using an array of unions.

If there are no compelling perf reassons to do otherwise, let us do
something which is obviously correct, rather than complicating
matters.

Stefano Stabellini writes ("Re: [PATCH v11 9/9] xen: explicit casts when DECLARE_BOUNDS cannot be used [and 1 more messages]"):
> On Thu, 7 Mar 2019, Ian Jackson wrote:
> > Jan has one suggestion, which I don't fully understand (see below).
> > Alternatively I suggest the following ad-hoc approach:

Probably, we should follow Jan's suggestion and not mine.

> > I also disagree with the wording of the comment.  It is seriously
> > misleading.  These symbols do in fact refer to the same object!
> > The problem is that the compiler thinks otherwise.  You need wording
> > like that in DECLARE_BOUNDS.  (Or a reference to it.)
> > 
> > > and if you think it is correct, then no
> > > matter what you do the behavior is undefined. Instead I view the
> > > entirety of the .bug_frames.* sections as a single array, with
> > > labels placed not only at start and end, but also in the middle. I
> > > think the code here would better also be taken care of by the
> > > DECLARE_BOUNDS() machinery, dividing the single array into
> > > multiple smaller ones.
> > 
> > Jan, I'm not sure exactly what you are suggesting.  Currently the
> > array has one pointer per element.  Are you suggesting it should have
> > two pointers (start and end), with different notional types ?
> 
> I am not fully understanding the suggestion either.
> 
> Even if we split it into multiple start-end pairs, still we won't be
> able to compare start/end of a pair with start/end of different pair
> without casts.

I don't think this bug_frames code does that ?  Maybe I have misread
it.

> This makes sense. Also, I understand _stext and __2M_rwdata_end better
> than the bug_frames and I should be able to write an half-decent
> explanation here. FYI _stext is already converted to DEFINE_BOUNDS in
> this series, but you are right that __2M_rwdata_end is not. I'll fix
> that.

Thanks.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel