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

[Jan Beulich <jbeulich@xxxxxxxx>]

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