Mailing List Archive: [PATCH 0 of 3] Introduce more debugging flexibility with ASSERT() macros

[PATCH 0 of 3] Introduce more debugging flexibility with ASSERT() macros

Oct 8, 2012, 11:16 AM

Post #1 of 3 (200 views)

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

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

Re: [PATCH 0 of 3] Introduce more debugging flexibility with ASSERT() macros [ In reply to ]

keir.xen at gmail

Oct 8, 2012, 11:31 AM

Post #2 of 3 (201 views)

Permalink

On 08/10/2012 19:16, "Andrew Cooper" <andrew.cooper3@citrix.com> 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

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

Re: [PATCH 0 of 3] Introduce more debugging flexibility with ASSERT() macros [ In reply to ]

andrew.cooper3 at citrix

Oct 9, 2012, 2:55 AM

Post #3 of 3 (193 views)

Permalink

On 08/10/12 19:31, Keir Fraser wrote:
> On 08/10/2012 19:16, "Andrew Cooper" <andrew.cooper3@citrix.com> 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

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