Re: [PATCH v6 03/14] xen: Use a typesafe to define INVALID_MFN

From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Elena Ufimtseva <elena.ufimtseva@oracle.com>,
	Julien Grall <julien.grall@arm.com>
Cc: Kevin Tian <kevin.tian@intel.com>,
	sstabellini@kernel.org, Jan Beulich <jbeulich@suse.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Liu Jinsong <jinsong.liu@alibaba-inc.com>,
	Christoph Egger <chegger@amazon.de>, Tim Deegan <tim@xen.org>,
	xen-devel@lists.xen.org, Paul Durrant <paul.durrant@citrix.com>,
	Jun Nakajima <jun.nakajima@intel.com>
Subject: Re: [PATCH v6 03/14] xen: Use a typesafe to define INVALID_MFN
Date: Fri, 8 Jul 2016 20:20:03 +0100	[thread overview]
Message-ID: <2f7cc943-38ab-394d-2ab5-c3b61850ed07@citrix.com> (raw)
In-Reply-To: <20160708220136.GA12597@localhost.localdomain>

On 08/07/2016 23:01, Elena Ufimtseva wrote:
>
>>> @@ -838,7 +838,6 @@ mfn_t oos_snapshot_lookup(struct domain *d, mfn_t gmfn)
>>>
>>>      SHADOW_ERROR("gmfn %lx was OOS but not in hash table\n", mfn_x(gmfn));
>>>      BUG();
>>> -    return _mfn(INVALID_MFN);
> Can compiler be unhappy about this?

This was my suggestion, from a previous round of review.

A while ago, I annotated BUG() with unreachable(), as as execution will
not continue from a bugframe, but the shadow code is definitely older
than my change.

As such, compilers will have been dropping this return statement as part
of dead-code-elimination anyway.

This option is better than just replacing one bit of dead code with a
different bit of dead code.

~Andrew

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