From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH 0 of 3] Introduce more debugging flexibility with ASSERT() macros Date: Mon, 08 Oct 2012 19:31:40 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper , xen-devel@lists.xen.org Cc: Jan Beulich List-Id: xen-devel@lists.xenproject.org On 08/10/2012 19:16, "Andrew Cooper" wrote: > The following three patches introduce several debugging macros I have > been using for a long time while debugging issues in Xen. > > ASSERT_PRINK() is hopefully obvious, and ASSERT_RUN() is useful when > more complicated printing is required. Are these going to get enough use to be worthwhile, rather than open-coding them where necessary? In many places we may not care about being able to disable the check-and-crash, so avoiding ifdefs is not necessarily a good argument. -- Keir > The final macro ASSERT_RUN_SINGLE() is not fit for upstream yet. It is > designed to force all other PCPUs into a wait loop in an NMI context, so > the ASSERT()'ing processor can walk data structures without locks, and > without fear that values are changing under its feet. I will work on > integrating this into the crash code (as it has a similar setup for the > start of the kexec_crash() path), and upstream when I have time. > > ~Andrew