From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: [PATCH 0 of 3] Introduce more debugging flexibility
 with ASSERT() macros
Date: Mon, 8 Oct 2012 19:16:00 +0100
Message-ID: <patchbomb.1349720160@andrewcoop.uk.xensource.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: xen-devel@lists.xen.org
Cc: Keir Fraser <keir@xen.org>, Jan Beulich <jbeulich@suse.com>
List-Id: xen-devel@lists.xenproject.org

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.

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