[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>>> On 17.01.19 at 01:37, <sstabellini@xxxxxxxxxx> wrote:
> On Wed, 16 Jan 2019, Jan Beulich wrote:
>> In any event - since intermediate variables merely hide the
>> casting from the compiler, but they don't remove the casts, the
>> solution involving casts is better imo, for incurring less overhead.
> 
> This is where I completely disagree. The intermediate variables are not
> hiding casts from the compiler. There were never any pointers in this
> case.  The linker creates "symbols", not pointers, completely invisible
> from C land. Assembly uses these symbols to initialize variables. We
> expose these assembly variables as integer to C lands. LD scripts and
> assembly have their own terminology and rules: neither "_start" nor
> "start" are pointers at any point in time. The operations done in var.S
> is not a cast. The C spec is happy, the compiler is happy, MISRA-C is
> happy. And we get to avoid the ugly SYMBOL macro that Linux uses. It is
> really a win-win.

Well, that's a position one can take. But we have to settle on another
aspect then first: Does what is not done in C underly C's rules? I
thought you were of the opinion that what comes from linker scripts
does. In which case what comes from assembly files ought to, too.
(FAOD my implication is: If the answer is yes, both approaches
violate C's rules. If the answer is no, no change is needed at all.)

Jan



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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.