From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <jbeulich@suse.com>, Oleksii <oleksii.kurochko@gmail.com>
Cc: George Dunlap <george.dunlap@citrix.com>,
Julien Grall <julien@xen.org>,
Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH v1 1/4] xen: introduce CONFIG_GENERIC_BUG_FRAME
Date: Thu, 16 Feb 2023 10:48:54 +0000 [thread overview]
Message-ID: <068340c3-2a2f-4bd0-20e9-f1dd6fe4bc2b@citrix.com> (raw)
In-Reply-To: <5f6d7b8e-907b-d3eb-335c-8d4a77edf526@suse.com>
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.
That said, I'm not sure an architecture could reasonably function
without a generic 4-byte PC-relative relocation...
~Andrew
next prev parent reply other threads:[~2023-02-16 10:49 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-03 17:05 [PATCH v1 0/4] introduce generic implementation of macros from bug.h Oleksii Kurochko
2023-02-03 17:05 ` [PATCH v1 1/4] xen: introduce CONFIG_GENERIC_BUG_FRAME Oleksii Kurochko
2023-02-13 12:24 ` Jan Beulich
2023-02-13 13:19 ` Julien Grall
2023-02-13 13:30 ` Jan Beulich
2023-02-13 13:56 ` Julien Grall
2023-02-13 15:02 ` Jan Beulich
2023-02-13 15:07 ` Julien Grall
2023-02-13 15:14 ` Jan Beulich
2023-02-13 13:33 ` Andrew Cooper
2023-02-13 13:55 ` Julien Grall
2023-02-14 16:22 ` Oleksii
2023-02-14 16:55 ` Jan Beulich
2023-02-15 15:06 ` Oleksii
2023-02-15 17:59 ` Oleksii
2023-02-16 7:31 ` Jan Beulich
2023-02-16 10:44 ` Oleksii
2023-02-16 12:09 ` Oleksii
2023-02-16 12:19 ` Andrew Cooper
2023-02-16 20:44 ` Oleksii
2023-02-17 7:12 ` Jan Beulich
2023-02-17 9:33 ` Oleksii
2023-02-16 14:55 ` Jan Beulich
2023-02-16 10:48 ` Andrew Cooper [this message]
2023-02-16 12:21 ` Oleksii
2023-02-16 14:53 ` Jan Beulich
2023-02-03 17:05 ` [PATCH v1 2/4] xen/arm: switch ARM to use generic implementation of bug.h Oleksii Kurochko
2023-02-13 13:02 ` Jan Beulich
2023-02-14 16:28 ` Oleksii
2023-02-03 17:05 ` [PATCH v1 3/4] xen/x86: switch x86 to use generic implemetation " Oleksii Kurochko
2023-02-13 13:10 ` Jan Beulich
2023-02-14 16:41 ` Oleksii
2023-02-03 17:05 ` [PATCH v1 4/4] xen: change <asm/bug.h> to <xen/bug.h> Oleksii Kurochko
2023-02-13 13:13 ` Jan Beulich
2023-02-14 16:44 ` Oleksii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=068340c3-2a2f-4bd0-20e9-f1dd6fe4bc2b@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=george.dunlap@citrix.com \
--cc=jbeulich@suse.com \
--cc=julien@xen.org \
--cc=oleksii.kurochko@gmail.com \
--cc=sstabellini@kernel.org \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.