On 16.02.2023 11:44, Oleksii wrote: > On Thu, 2023-02-16 at 08:31 +0100, Jan Beulich wrote: >> On 15.02.2023 18:59, Oleksii wrote: >>> 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()?) > Hmm. I don't know other ways to express an immediate operand except > 'i'. > > It looks like type, line, msg are always 'constants' > ( > they possibly can be passed without 'i' and used directly inside asm(): > ... > ".pushsection .bug_frames." __stringify(type) ", \"a\", > %progbits\n"\ > ... > ) but the issue will be with 'ptr' for which we have to use 'i'. > > And I am not sure about all 'constants'. For example, I think that it > can be an issue with 'line' = '((line & ((1 << BUG_LINE_LO_WIDTH) - 1)) > << BUG_DISP_WIDTH)' if we will use that directly inside asm(...).
Not matter how complex an expression, the compiler will evaluate it to a plain number if it's a constant expression. The only think to worry about with "i" is, as said, is the value supplied is the address of some symbol (or an expression involving such). Jan
