[U-Boot] [PATCH v3 0/8] add clang support for some ARM boards

Albert ARIBAUD albert.u.boot at aribaud.net
Thu Sep 11 15:31:07 CEST 2014


Hi Jeroen,

On Thu, 11 Sep 2014 13:17:20 +0200, Jeroen Hofstee
<jeroen at myspectrum.nl> wrote:

> Hello Albert,
> 
> On do, 2014-09-11 at 10:32 +0200, Albert ARIBAUD wrote:
> 
> > 
> > On Wed, 10 Sep 2014 20:08:50 +0200, Jeroen Hofstee
> > <jeroen at myspectrum.nl> wrote:
> > 
> > > Changes since v2:
> > >    - As Albert pointed out the clang instructions don't work with
> > >      Debian based binary packages. While I was aware of that it is
> > >      for a different reason then I thought, it is not that ARM is not
> > >      enabled as a backend but older versions are a bit more picky on
> > >      the target argument and don't tolerate a trailing dash to it as
> > >      used for CROSS_COMPILE etc. The README is updated accordingly.
> > > 
> > >      As a side note clang3.5-svn as shipped in Ubuntu is not the 3.5
> > >      release but an snapshot of some svn commit and hence explain why
> > >      the recompiled 3.5 can behave different then the ubuntu clang-3.5.
> > >      Since it misses some patches, the clang3.5-svn can build less
> > >      boards then 3.4 or an actual 3.5 release.
> > > 
> > >    - While add it, include Masahiro suggestion to also use c++ instead
> > >      of g++.
> > >    - Drop dependencies from the cover-letter as they are merged.
> > >    - only patch 7/8 and 8/8 are reposted. 1..6 are the same as v2.
> > 
> > Thanks, tested building rpi_b, it works now.
> > 
> > The, tested on versatileqemu out of curiosity and got the following
> > results:
> > 
> > 1.
> > 
> > clang warns about Unused static functions in common/console.c, namely
> > console_printdevs and console_doenv (1). Why gcc does not flag this?
> > We have -Wall set which is supposed to imply -Wunused-functions.
> 
> It is a gcc feature, see [1]: "Warn whenever a static function is
> declared but not defined or a _non-inline static function_ is unused.
> This warning is enabled by -Wall."

Ok, I'll assume there is some logic in there, but then, clang does not
follow that logic -- so which one is the 'good' one? Or maybe that's
the same as the second issue, where...

> > There is also an unused variable warning in disk/part.c28
> > (block_drvr). I haven't looked at why clang warns about it and not gcc,
> > but it could raise the same question as the functions above.
> 
> Also a gcc feature, see [2]. The constant is indeed not used.

... apparently, it's a case of trying to balance false positives and
missed true issue, and each team has its own view of where to set
the limit. :/

(anyway -- here clearly, clang is right in warning us and gcc is wrong
in not doing it)

> > 2.
> > 
> > clang errors on arch/arm/lib/cache.c:28 for this:
> > asm("0: mrc p15, 0, r15, c7, c10, 3\n\t" "bne 0b\n" : : : "memory");
> > and that is a clang mistake, as for ARM926EJS r15 is a valid (albeit
> > quite special semantically) Rd for Test and Clean DCache, see page 2-24.
> > 
> 
> This is the integrated-as complaining (the README tells you to disable
> it for the moment). The clang folks push UAL hard, up to a point we need
> to think about minimum gcc version etc. To avoid that, I just left out
> such changes and just use gas instead, at least for the time being.
> Below are some changes to compile versatileqemu with llvm integrated-as
> and gcc/gas. No idea if it actually boots though.
> 
> > Jeroen, do you feel like raising point 2 to the clang/LLVM folks?
> 
> It is removed on purpose as far as I understood. I don't think they
> regards it as a bug, see obfuscated patch below. 
> 
> > Other than that, the patch series seems to be good. I'll apply it
> > soonish.
> > 
> 
> Thanks,
> Jeroen

> ~       "mrc p15, 0, r15, c7, c14, 3\n"
> +       "mrc p15, 0, apsr_nzcv, c7, c14, 3\n"

Is this is a hack to set the Rd field of the mrc instruction to a value
equal to what "r15" would have given, but fooling clang by using an
unrelated and, in this context, meaningless, symbol instead of "r15"?

Amicalement,
-- 
Albert.


More information about the U-Boot mailing list