On 07/03/2011 15:38, "Tim Deegan" <Tim.Deegan@xxxxxxxxxx> wrote:
> At 15:15 +0000 on 07 Mar (1299510944), Keir Fraser wrote:
>> On 07/03/2011 15:05, "Keir Fraser" <keir.xen@xxxxxxxxx> wrote:
>> 
>>> On 07/03/2011 11:26, "Tim Deegan" <Tim.Deegan@xxxxxxxxxx> wrote:
>>> 
>>>> (dump_execution_state()) as its own bug-trap.
>>>> 
>>>> This is needed to compile xen with clang, which can't handle using a
>>>> function name in an asm immediate.
>>> 
>>> Actually run_in_exception_handler() does have another user, in ns16550.c.
>>> Although non-essential, it makes the 'd' debug key much more useful when
>>> running the UART in polled mode.
>>> 
>>> So I suggest we keep run_in_exception_handler but modify it to pass the
>>> function pointer in (say) rAX.
>> 
>> Like the attached patch (against latest tip).
>
> 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!
 -- 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@xxxxxxxxxx>
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>>>> http://lists.xensource.com/xen-devel 
>>> 
>>> 
>> 
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel