Re: [PATCH 6 of 8] Xen: remove run_in_exception_handler() and recode its only caller

[Keir Fraser <keir.xen@gmail.com>]

On 07/03/2011 15:44, "Keir Fraser" <keir.xen@gmail.com> wrote:

>> 
>> Sorry, I had missed that other user.  I'll see if I can find a way to
>> make clang use the function address directly; if not, I'd be inclined to
>> have dump_execution_state have its own ID anyway, to keep %rax valid(er)
>> in BUG()s.
> 
> But actually dump_execution_state() isn't used for BUGs and WARNs and
> ASSERTs. In fact it's practically dead on x86 -- it's used in one rather
> unlikely ACPI error function, and also in __bug/__warn which are never used
> on x86. And that's it. Actually the user of run_in_exception_handler() in
> ns16550.c is really the only one we care about!

And furthermore, the GPRs dumped from the 'd' key via a UART in polled mode
are always uninteresting. Because the backtrace will start from ns16550_poll
and out from there through Xen's timer subsystem. The fact we clobber rAX in
r_i_e_h() would not make things worse. :-)

So if you can't find a way to force a function address through clang then my
patch would be a perfectly fine alternative.

 -- Keir

>  -- Keir
> 
>> Tim.
>> 
>>>> I think we won't easily be able to use
>>>> BUG_STR() logic but r_i_e_h is only used (directly or indirectly) in a few
>>>> places so the BUG_STR optimisation is unimportant. The only other
>>>> disadvantage is that rAX is less interesting in the state dump, but any
>>>> value the function pointer displaces can still be found in the stack dump,
>>>> albeit with likely a little extra effort.
>>>> 
>>>> Sound good?
>>>> 
>>>>  -- Keir 
>>>> 
>>>>> Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Xen-devel mailing list
>>>>> Xen-devel@lists.xensource.com
>>>>> http://lists.xensource.com/xen-devel
>>>> 
>>>> 
>>> 
>> 
>> 
> 
>