[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v1 1/4] xen: introduce CONFIG_GENERIC_BUG_FRAME


  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 16 Feb 2023 15:53:33 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=JDs2O3VVhyh85GlUhnqv5pwjP1qkQcmxOEnS2XD9Ny4=; b=Kz8OYpv3KlR1WPfC+WJ0+iDd/6os/wuGYb6chjzIqgjowml0cH+frLrqrE+Y597VIVRb7KoJyVvhotJFxlT8QzI6ye7OkTBD/P33H0D+v3k6PAUMjldDRqmEtrkOElQ/bMw3b/P+4ILnstCRS8QIAkPZaecrh8mNybMMJ4A1bGM5tOZk5J7Bp3F0HGqoM0tta3jiA0+0d8EHPbovwTol4P5Rma+MPdDgTHc1DNyD30IfUchnvbleSvDSDvv+a+Fyk3G/2UyS8igNQZqNdkwZI8ajTta2hYJQTchwmUncAnEgz8N+05PjMrU2jvEqnWt7afblzwKV9oq9Ib73jWEMCA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GbDl79AugHjKy5Kz5RtykojN0LA7JSzRRTk/XU3Knnf3SA8CLPkb0KAozb8jd6B9otnzY+Emmuk1yZlePPZSeJD+M2vG2E9jzdQn46qjAC8/lnyfUxhKvoLD8ztaWLsbSak5ea1fsR2lLIvAQ2gvpu+3pEXBGcQu0LFA1nVysLJzjNBTdglVIVRdZ1ywB2NW+Y2NfjtPEADvaHcj4vtiV+Sh/5RoJbeCJsMKuAPy8CzleR5NYVERdOAZ4NL4ko6tWJkWnhmF7kQlw3+9XiX7CjtUaOkrQEM4LJ6FakWK8Rxghu4hT+BzCdGUhfQ9Jjj8WUpEkKptPme0b4VYvH1LMw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx, Oleksii <oleksii.kurochko@xxxxxxxxx>
  • Delivery-date: Thu, 16 Feb 2023 14:53:46 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 16.02.2023 11:48, Andrew Cooper wrote:
> On 16/02/2023 7:31 am, Jan Beulich wrote:
>> On 15.02.2023 18:59, Oleksii wrote:
>>> Hello Jan and community,
>>>
>>> I experimented and switched RISC-V to x86 implementation. All that I
>>> changed in x86 implementation for RISC-V was _ASM_BUGFRAME_TEXT. Other
>>> things are the same as for x86.
>>>
>>> For RISC-V it is fine to skip '%c' modifier so _ASM_BUGFRAME_TEXT will
>>> look like:
>>>
>>> #define _ASM_BUGFRAME_TEXT(second_frame) \
>>>     ".Lbug%=: ebreak\n"   
>>>     ".pushsection .bug_frames.%[bf_type], \"a\", @progbits\n"
>>>     ".p2align 2\n"
>>>     ".Lfrm%=:\n"
>>>     ".long (.Lbug%= - .Lfrm%=) + %[bf_line_hi]\n"
>>>     ".long (%[bf_ptr] - .Lfrm%=) + %[bf_line_lo]\n"
>>>     ".if " #second_frame "\n"
>>>     ".long 0, %[bf_msg] - .Lfrm%=\n"
>>>     ".endif\n"
>>>     ".popsection\n"
>> I expect this could be further abstracted such that only the actual
>> instruction is arch-specific.
>>
>>> The only thing I am worried about is:
>>>
>>> #define _ASM_BUGFRAME_INFO(type, line, ptr, msg) \
>>>   [bf_type] "i" (type), ...
>>> because as I understand it can be an issue with 'i' modifier in case of
>>> PIE. I am not sure that Xen enables PIE somewhere but still...
>>> If it is not an issue then we can use x86 implementation as a generic
>>> one.
>> "i" is not generally an issue with PIE, it only is when the value is the
>> address of a symbol. Here "type" is a constant in all cases. (Or else
>> how would you express an immediate operand of an instruction in an
>> asm()?)
> 
> At a guess, the problem isn't type.  It's the line number, which ends up
> in a relocation.

Why would that be a problem? If there's a relocation in the first place
(not because of the line number, but because of the other part of the
expression), then it would only alter the addend of that relocation.

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.