[cfe-dev] clang building linux

[pageexec at freemail.hu]

On 26 Oct 2010 at 11:47, Bryce Lelbach wrote:

hi,

> > 2. probably related to the above, __builtin_memcpy and __builtin_memset also
> >    ignore -mregparm and cause the same kind of trouble at runtime so i worked
> > it around by using explicit inline asm.
> 
> I'm curious as to where this was causing problems?

there's a structure copy in arch/x86/boot/memory.c (see the patch) that in clang
ends up calling the builtin (vs. an inlined 'rep movs' in gcc) and since the calling
convention was wrong on it, i had to make it an explicit memcpy (that'd call my
own quick hack in turn).

> > 4. unused variable/function elimination
> > 
> >    it seems that clang is more aggressive than gcc and eliminates more
> > actually required data/code than desired. earliest causalty is the boot code
> > as usual but there're also some module parameter related structures affected.
> > the fix is needed on the linux side of course.
> 
> I'm working on a static analysis to show us where this is.

how are you going to do it? in the boot code the problem is that linux (ab)uses
the linker script to build an otherwise C level array (some video mode setting
stuff) where each element is static in its respective compilation unit (and all
the  functions referenced from there are static too) so all a static analyzer
could notice is that there's not much useful code/data emitted into the object
file, it won't know that at a higher level (and in a separate compilation unit)
those omitted structures/etc would actually be used.

> > 5. asm 'p' constraint
> > 
> >    this was fixed last week in subversion, so i'm omitting the patch for it,
> > but if someone really wants to use an earlier clang (such as the 2.8
> > release), then just duplicate the percpu_read macro into percpu_read_stable.
> 
> I have this fixed locally, not sure if I pulled this change in (I'm thinking I
> didn't).

it was fixed last week in svn.

> > 10. clang crash on __verify_pcpu_ptr use
> > 
> >     when compiling i think init/main.c, clang crashes on the above macro. i
> > tried to extract a minimal example but that failed to produce any errors, so
> > probably there is more context needed to trigger the segfault. interestingly,
> > the workaround for getting this compiled was to turn the body of the macro
> > into a statement expression but otherwise it's the same code inside.
> 
> Huh. I've never run into this. Would you be willing to pass along the build
> environment (configuration, platform, compiler version, etc)?

i just use svn head of llvm/clang and whatever linux/pax version is the latest.
i'll mail you a config but i don't think there's anything special in it, it's
a basic amd64/smp setup and in general, the linux percpu code doesn't depend on
.config much.

> > 14. clang's address_space attribute extension
> > 
> >     this would probably allow to simplify all the x86 per-cpu accessors (ditto
> >     for userland btw).
> 
> I don't think we'd get upstream to accept these, but +1 from me.

given that there're compiler specific headers to support various features in
them, i'd say this is no different and has a fair chance albeit the changes
needed will require some good abstraction of the x86 percpu accessor macros.

> It sounds like we (whoever's working on this at Pax and myself) could benefit
> from trading information and code here. I'm pretty comfortable with the Clang
> internals and less familiar with the Linux Kernel, and it sounds like you guys
> are more familiar with the Kernel and less familiar with Clang's internals.

sure, no problem, although my goal is to eventually catch up with the llvm/clang
side of things as well ;).