From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH 0 of 3] Introduce more debugging flexibility with ASSERT() macros Date: Tue, 9 Oct 2012 10:55:42 +0100 Message-ID: <5073F49E.3020204@citrix.com> 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: Keir Fraser Cc: Jan Beulich , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 08/10/12 19:31, Keir Fraser wrote: > 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 I hope that ASSERT_PRINTK() will start seeing quite a lot of use, especially with compound conditional statements where is is impossible from crash to see which of the individual conditionals failed. ASSERT_RUN() perhaps not so, but having it available means one less thing to opencode when debugging. I had not considered the case for {WARN,BUG}_PRINTK() which have the same argument as ASSERT_PRINTK(). Would you like to see them introduced as well? ~Andrew > >> 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 > -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com