Xen devel - Jun 2006 - Re: [Xen-changelog] [xen-unstable] [XEN] BUG() places console in sync mode.

On Jun 30, 2006, at 11:40 AM, Xen patchbot-unstable wrote:
> # HG changeset patch
> # User kfraser@dhcp93.uk.xensource.com
> # Node ID 1d17ddd9e45d25e1b5fc21e558a4973b70572334
> # Parent  25c6ea6d4024c86c2dfd54ef9f44c793e7346ee8
> [XEN] BUG() places console in sync mode.
> Also move the BUG code out of line.
> Original patch from Jimi Xenidis.
> diff -r 25c6ea6d4024 -r 1d17ddd9e45d xen/include/xen/lib.h
[...]
> +extern void __bug(char *file, int line) __attribute__((noreturn));
I can understand panic() being "noreturn", which it isn''t,
but __bug
() should not, since It should result in some debugging logic (gdb,  
xmon, whatever) that could potentially continue.

-JX

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

On 30 Jun 2006, at 16:57, Jimi Xenidis wrote:
>> [XEN] BUG() places console in sync mode.
>> Also move the BUG code out of line.
>> Original patch from Jimi Xenidis.
>> diff -r 25c6ea6d4024 -r 1d17ddd9e45d xen/include/xen/lib.h
> [...]
>> +extern void __bug(char *file, int line) __attribute__((noreturn));
>
> I can understand panic() being "noreturn", which it
isn''t, but __bug()
> should not, since It should result in some debugging logic (gdb, xmon, 
> whatever) that could potentially continue.
Is it used in any contexts other than where some pretty serious error 
has occurred and all you want to do is postmortem? I don''t think 
continuing would ever be be helpful or sane.

  -- Keir


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

On Jun 30, 2006, at 12:04 PM, Keir Fraser wrote:
>
> On 30 Jun 2006, at 16:57, Jimi Xenidis wrote:
>>
>> I can understand panic() being "noreturn", which it
isn''t, but
>> __bug() should not, since It should result in some debugging logic  
>> (gdb, xmon, whatever) that could potentially continue.
>
> Is it used in any contexts other than where some pretty serious  
> error has occurred and all you want to do is postmortem? I don''t  
> think continuing would ever be be helpful or sane.
So:
  panic(): STOP but eventually reboot
  __bug(): STOP and loop forever for postmortem/debugging cannot be  
suppressed
  ASSERT(): STOP but can be suppressed (!NDEBUG )

Panic is very serious, but BUG and ASSERT, to me, are used to  
indicate some error in programming logic, if that error can be  
"fixed" during a debugging session then the ability to continue is  
quite valuable, especially if it takes a long time ot get to the BUG().

if it is not BUG, then perhaps we can introduce something like  
BREAKPOINT() that can be used for this purpose?

-JX




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

On 4 Jul 2006, at 18:01, Jimi Xenidis wrote:
> Panic is very serious, but BUG and ASSERT, to me, are used to indicate 
> some error in programming logic, if that error can be "fixed"
during a
> debugging session then the ability to continue is quite valuable, 
> especially if it takes a long time ot get to the BUG().
I really can''t conceive a situation where it would be handy to be able 
to rectify a bug from within a debugger in order to carry on executing. 
I''ve never wanted to do that.
> if it is not BUG, then perhaps we can introduce something like 
> BREAKPOINT() that can be used for this purpose?
Sure.

  -- Keir


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