Re: [Xen-devel] [PATCH v6 1/4] xen: introduce SYMBOL

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 16.01.19 at 00:36, <sstabellini@xxxxxxxxxx> wrote:
> On Tue, 15 Jan 2019, Jan Beulich wrote:
>> First of all we should explore whether the variables could also be
>> linker generated, in particular to avoid the current symbols to be
>> global (thus making it impossible to access them from C files in the
>> first place).
> 
> That would be fantastic. I looked around, I found interesting things
> like PROVIDE, but I don't think what you describe is possible. The
> linker scripts only define symbols, they cannot set or define variables.

Yeah, it didn't seem very likely. Then again I think the next best
approach would still be to use .startof. / .sizeof., just not the
way my original patch did, but in your var.S file(s). The
fundamental goal still being to avoid exposure of the symbols
we don't want to be used in C altogether. (All of this provided
we need to go this intermediate variable route in the first place,
which I continue to be unconvinced of, despite you having
posted a respective v8 of your series.)

>> Failing that, I don't think it matters much where these
>> helper symbols live, and hence your choice is probably fine (I'd
>> prefer though if, just like on Arm, the x86 file didn't live in the
>> boot/ subdirectory; in the end it might even be possible to have
>> some of them in xen/common/var.S).
> 
> OK, I'll move the x86 var.S to xen/arch/x86/x86_64. I cannot share var.S
> because arm32 is using long instead of quad.

Excuse me, but no. This is extremely easy to abstract away - see
x86 Linux'es _ASM_PTR.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel