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()?) Jan
