[llvmlinux] Multiple storage class error
behanw at converseincode.com
Sun Nov 17 15:45:48 UTC 2013
On 11/17/13 02:38, Renato Golin wrote:
> On 16 November 2013 21:54, Behan Webster <behanw at converseincode.com
> <mailto:behanw at converseincode.com>> wrote:
> We'd actually like to replace it's use with
> __builtin_stack_pointer() (something we're trying to get added to
> both clang and gcc).
> I know. Did you get far in the GCC list? I think we all agree it would
> be a good addition in Clang.
Not yet. I've been busy with courses, so this hasn't had my full
attention as of late.
>> #else /* gcc */
>> This is horrendous! Is this in the kernel, or is it one of our
>> local patches?
> That is the way it is currently done in the kernel with gcc. I've
> merely moved it to one place from the various places it is copied
> to in the ARM portion of the kernel.
> The x86 kernel does exactly this (define a global named register
> variable to access "esp").
> I expected as much. ;) Sigh...
There really isn't a better way of doing it right now.
>> #else should *only* have one of:
>> * A behaviour that is commonly known as global, generally as an
>> alternative to a very specific behaviour in the
> Which is exactly what this patch does.
> Not really. The #else code contains a GCC extension, which is not in
> the C standard, is using undefined behaviour and was not an extension
> agreed across multiple compilers (like __builtin_stack_pointer would be).
Have you read the kernel? It uses gcc extensions everywhere. The kernel
devs don't pretend to follow the standard, nor are they sorry for doing
so. Arguing "standard C" doesn't wash with them. The problem is that the
C standard has mostly not been sufficient for their needs. It has only
recently caught up with the Linux kernel, and in many cases has codified
what they've been doing as a gcc extension for 10+ years. The #else MUST
be the gcc case, because gnu90 (gcc's gnu89 with some c99 backported,
gcc's default right now) code is the "standard" currently followed in
the kernel. Essentially for many devs if it works with gcc, it's good.
This is why I argue the benefits of the new code, and not why the
current code might be wrong. The one thing we can not do is break the
gcc build. clang is very much a second class citizen at this point until
we get all our patches upstreamed. To put it another way, clang support
in the kernel can not negatively impact the use of gcc in any way by any
of our patches. That's just the way it is.
>> * An error message
> Which would break the kernel. gcc IS the default case.
> Well, isn't that what we're trying to change?
No we're not. I'd bet that the default will always be gcc. There is just
too much history for it not to be the default.
> What I'm saying is that, since we're now changing the kernel to become
> compiler-agnostic, we might just as well fix the GCC-specific
> assumptions, at least on the parts we touch.
We are enabling the choice of using clang instead of gcc for those who
choose to do so. Ideally in a way which is as equal as we can get to
what gcc is currently doing.
Being compiler agnostic is well beyond our goals at this point (of
enabling clang as a choice). Being completely compiler agnostic will
require convincing most (if not all) the kernel community that having
more than one compiler is a good idea. That will take a lot more time.
Having said that, the KBuild changes I've tried to add aren't clang
specific. However, they do assume gcc as the default. There are new
$HOSTCOMPILER and $COMPILER variables which, if unset, are assumed to be
gcc. We of course set them appropriately depending on what $HOSTCC and
$CC are set to. Sadly there are situations in KBuild where we have to do
special things if $COMPILER == "clang".
> So, in that case, you could have an #elif __gcc with the GCC case and
> an #else with an error message "Compiler doesnt support
> builtin_whatever". Once the builtin is accepted on both compilers, you
> can merge them all, but still leave the #error, so that new compilers
> will have a very nice message telling them to implement the builtin.
Hm. I see what you're suggesting. I suppose that would work.
> Of course, discussing the best course of action and the final solution
> would be something the kernel maintainers would have to agree 100%,
> even if they don't agree with me. ;)
I find small steps are usually the easiest to get accepted upstream.
> Currently in the ARM kernel they are all spread out as local
> register variables. In the x86 kernel they are done as a global
> (like my patch is trying to do now for ARM).
> Got it. Keeping in mind that different compilers have different
> linkage types for static/global/register variables, I believe that
> this could work. Having the builtin would be better in that aspect,
> too, since all compilers could agree on the linkage type for that.
behanw at converseincode.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the LLVMLinux