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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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