[llvmlinux] "make test" for x86_64 target just hung there, why?

Daniel Sanders Daniel.Sanders at imgtec.com
Sat Sep 12 12:03:35 UTC 2015


I didn't know C99 changed the meaning of the inline keyword. Thanks for pointing that out and explaining.

> $ git diff
> diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
> index 929a3f0d2b08..bef8281d8588 100644
> --- a/include/linux/compiler-gcc.h
> +++ b/include/linux/compiler-gcc.h
> @@ -75,12 +75,12 @@
>  #define __inline       __inline        __attribute__((always_inline)) notrace
>  #else
>  /* A lot of inline functions can cause havoc with function tracing */
> -#define inline         inline          notrace __maybe_unused
> -#define __inline__     __inline__      notrace __maybe_unused
> -#define __inline       __inline        notrace __maybe_unused
> +#define inline         notrace __maybe_unused
> +#define __inline__     notrace __maybe_unused
> +#define __inline       notrace __maybe_unused
>  #endif
> 
> -#define __always_inline        inline __attribute__((always_inline))
> +#define __always_inline
>  #define  noinline      __attribute__((noinline))
> 
>  #define __deprecated   __attribute__((deprecated))

Yes, that's the right change. If you haven't already done so you should double check those are macros that are used. I see there's another set of definitions just above the #else.

> > I'm fairly certain it was compiler-gcc.h but you can double check by adding a '#error "foo"' to
> > one of them and see if you get this forced error when you rebuild. If you do, then the header
> > is included in your build. You can also use this technique to find the exact macro that gets
> > defined by placing the #error next to it.
>
> 
> Do you have an example line for me?

Just:
  #error "foo"
will do the trick. The pre-processor will emit an error with the message "foo" when it encounters it so seeing that error or not can tell you whether a line was pre-processed or not.

> Unfortunately, changes to compiler-gcc.h re-builds all asm-related files :-(.

I'm afraid so, but if you're careful you can trick make into thinking most things are already built. 'find -type f | xargs touch' on your build tree will tell make everything is up to date, then you can delete the objects you want to rebuild. This can speed up debugging a lot but it carries a risk of broken/incomplete builds.
________________________________________
From: Sedat Dilek [sedat.dilek at gmail.com]
Sent: 12 September 2015 12:36
To: Daniel Sanders
Cc: pageexec at gmail.com; llvmlinux at lists.linuxfoundation.org; David Woodhouse
Subject: Re: [llvmlinux] "make test" for x86_64 target just hung there, why?

On Sat, Sep 12, 2015 at 1:15 PM, Daniel Sanders
<Daniel.Sanders at imgtec.com> wrote:
[...]

>> You point exactly where I want to play with...
>> There is a include/linux/compiler-gcc.h file where inlining is defined
>> (see below) plus LLVMLinux has an own include/linux/compiler-clang.h
>> file.
>
> You've found the right place. It seems they aren't just inlining (I'd forgotten about notrace and __maybe_unused) so we don't want to make them completely empty. We just want to remove inline (and it's alternate underscored spellings) and the always_inline attribute from the expansion like this:
> #define inline          inline          __attribute__((always_inline)) notrace __maybe_unused
> becomes:
> #define inline          notrace __maybe_unused
> and likewise for all the spellings of the inline and always_inline macros.  Leave the noinline one alone though since that's preventing inlining for the trivial cases compilers tend to inline automatically.
>

Something like this...?

$ git diff
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 929a3f0d2b08..bef8281d8588 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -75,12 +75,12 @@
 #define __inline       __inline        __attribute__((always_inline)) notrace
 #else
 /* A lot of inline functions can cause havoc with function tracing */
-#define inline         inline          notrace __maybe_unused
-#define __inline__     __inline__      notrace __maybe_unused
-#define __inline       __inline        notrace __maybe_unused
+#define inline         notrace __maybe_unused
+#define __inline__     notrace __maybe_unused
+#define __inline       notrace __maybe_unused
 #endif

-#define __always_inline        inline __attribute__((always_inline))
+#define __always_inline
 #define  noinline      __attribute__((noinline))

 #define __deprecated   __attribute__((deprecated))


> I'm fairly certain it was compiler-gcc.h but you can double check by adding a '#error "foo"' to one of them and see if you get this forced error when you rebuild. If you do, then the header is included in your build. You can also use this technique to find the exact macro that gets defined by placing the #error next to it.
>

Do you have an example line for me?

Unfortunately, changes to compiler-gcc.h re-builds all asm-related files :-(.

- Sedat -


More information about the LLVMLinux mailing list