This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH 6 of 8] Xen: remove run_in_exception_handler() an

To: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 6 of 8] Xen: remove run_in_exception_handler() and recode its only caller
From: Keir Fraser <keir.xen@xxxxxxxxx>
Date: Mon, 07 Mar 2011 15:49:17 +0000
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 07 Mar 2011 07:49:59 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:user-agent:date:subject:from:to:cc:message-id :thread-topic:thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=LcQ/nIID0dTM5JeKUdwgMVNyZk1UFPj7WF004+gmpcA=; b=APuWYDVjWqVC6KYik5QALiogq3dREcXUiCNfEtATV40fukLL/mkwd/YRoFw4E1wBFo yJnZfSTo8+Zu+OrpSYrSkgKPTbskmS3+wOG0fPzGfP95gpoEqQuIXB0qC4E+INvHP2CH oNH+GEjYPY8NpbeAdzxrSQNpf0SjY8H7skRb4=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=dBnRvwd0vf2QK52cXtmwSpSlF1LDH94TB7+9dCPKWzkPNRSnScYVBlX5fABsjdJPPy 4l5AZi2HzSzGryUL0k4vj3y3j1iYBhLtt5MumSxT6KrwB//bi68hz20iN4iTpap+0llq XZrlnIGl2B/VBpUETClWfFWY9SsUJPMTvgnKk=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C99AADF3.14421%keir.xen@xxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acvc3piG4uH2rIf2pECJxxB7QttHnwAAJ6PX
Thread-topic: [Xen-devel] [PATCH 6 of 8] Xen: remove run_in_exception_handler() and recode its only caller
User-agent: Microsoft-Entourage/
On 07/03/2011 15:44, "Keir Fraser" <keir.xen@xxxxxxxxx> 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@xxxxxxxxxx>
>>>>> _______________________________________________
>>>>> Xen-devel mailing list
>>>>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>>>>> http://lists.xensource.com/xen-devel

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>