<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 11/17/13 02:38, Renato Golin wrote:<br>
</div>
<blockquote
cite="mid:CAMSE1kcr+3ghCX__kjjxVs7k3MPCpx4Xw3j3zmVNyz8KxS0ecQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On 16 November 2013 21:54, Behan
Webster <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:behanw@converseincode.com" target="_blank">behanw@converseincode.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div class="im">
<div><span style="color:rgb(34,34,34)">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).</span></div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>I know. Did you get far in the GCC list? I think we all
agree it would be a good addition in Clang.</div>
</div>
</div>
</div>
</blockquote>
Not yet. I've been busy with courses, so this hasn't had my full
attention as of late.<br>
<br>
<blockquote
cite="mid:CAMSE1kcr+3ghCX__kjjxVs7k3MPCpx4Xw3j3zmVNyz8KxS0ecQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div class="im">
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">
<div>
<div>#else /* gcc */</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>This is horrendous! Is this in the
kernel, or is it one of our local patches?</div>
</div>
</div>
</div>
</blockquote>
</div>
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.<br>
<br>
The x86 kernel does exactly this (define a global named
register variable to access "esp").</div>
</blockquote>
<div><br>
</div>
<div>I expected as much. ;) Sigh...</div>
</div>
</div>
</div>
</blockquote>
There really isn't a better way of doing it right now.<br>
<br>
<blockquote
cite="mid:CAMSE1kcr+3ghCX__kjjxVs7k3MPCpx4Xw3j3zmVNyz8KxS0ecQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div class="im">
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>#else should *only* have one of:</div>
<div> * A behaviour that is commonly known as
global, generally as an alternative to a
very specific behaviour in the</div>
</div>
</div>
</div>
</blockquote>
</div>
Which is exactly what this patch does.</div>
</blockquote>
<div><br>
</div>
<div>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).</div>
</div>
</div>
</div>
</blockquote>
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.<br>
<br>
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.<br>
<br>
<blockquote
cite="mid:CAMSE1kcr+3ghCX__kjjxVs7k3MPCpx4Xw3j3zmVNyz8KxS0ecQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div class="im">
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> * An error message</div>
</div>
</div>
</div>
</blockquote>
</div>
Which would break the kernel. gcc IS the default case.<br>
</div>
</blockquote>
<div><br>
</div>
<div>Well, isn't that what we're trying to change?</div>
</div>
</div>
</div>
</blockquote>
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.<br>
<br>
<blockquote
cite="mid:CAMSE1kcr+3ghCX__kjjxVs7k3MPCpx4Xw3j3zmVNyz8KxS0ecQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>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.</div>
</div>
</div>
</div>
</blockquote>
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.<br>
<br>
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.<br>
<br>
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".<br>
<br>
<blockquote
cite="mid:CAMSE1kcr+3ghCX__kjjxVs7k3MPCpx4Xw3j3zmVNyz8KxS0ecQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>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.</div>
</div>
</div>
</div>
</blockquote>
Hm. I see what you're suggesting. I suppose that would work.<br>
<br>
<blockquote
cite="mid:CAMSE1kcr+3ghCX__kjjxVs7k3MPCpx4Xw3j3zmVNyz8KxS0ecQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>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. ;)</div>
</div>
</div>
</div>
</blockquote>
Exactly.<br>
<br>
I find small steps are usually the easiest to get accepted upstream.<br>
<br>
<blockquote
cite="mid:CAMSE1kcr+3ghCX__kjjxVs7k3MPCpx4Xw3j3zmVNyz8KxS0ecQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">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).</div>
</blockquote>
<div><br>
</div>
<div>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.</div>
</div>
</div>
</div>
</blockquote>
Right. :)<br>
<br>
Behan<br>
<pre class="moz-signature" cols="72">--
Behan Webster
<a class="moz-txt-link-abbreviated" href="mailto:behanw@converseincode.com">behanw@converseincode.com</a></pre>
</body>
</html>