[PATCH] MIPS: define __current_thread_info inside of function

[PATCH] MIPS: define __current_thread_info inside of function

[Hauke Mehrtens]

__current_thread_info is currently defined in the header file, but when
we link the kernel with LTO it shows up in all files which include this
header file and causes conflicts with itself. Move the definition into
the only function which uses it to prevent these problems.

This fixes the build with LTO.

Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
 arch/mips/include/asm/thread_info.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/mips/include/asm/thread_info.h b/arch/mips/include/asm/thread_info.h
index 4993db40482c..9348776e16a3 100644
--- a/arch/mips/include/asm/thread_info.h
+++ b/arch/mips/include/asm/thread_info.h
@@ -49,11 +49,11 @@ struct thread_info {
 	.addr_limit	= KERNEL_DS,		\
 }
 
-/* How to get the thread information struct from C.  */
-register struct thread_info *__current_thread_info __asm__("$28");
-
 static inline struct thread_info *current_thread_info(void)
 {
+	/* How to get the thread information struct from C.  */
+	register struct thread_info *__current_thread_info __asm__("$28");
+
 	return __current_thread_info;
 }
 
-- 
2.11.0

Re: [PATCH] MIPS: define __current_thread_info inside of function

[Ralf Baechle]

On Sat, Jun 16, 2018 at 05:58:15PM +0200, Hauke Mehrtens wrote:

> __current_thread_info is currently defined in the header file, but when
> we link the kernel with LTO it shows up in all files which include this
> header file and causes conflicts with itself. Move the definition into
> the only function which uses it to prevent these problems.
> 
> This fixes the build with LTO.

Not a new issue, see

  https://git.linux-mips.org/cgit/ralf/linux-lto.git/commit/arch/mips/include/asm/thread_info.h?id=969890d139ee53f61fc6ed3f534335802c733e1b

This was never upstreamed since LTO never received much love from upstream
back then and there might be more well ripened code in there.

To me this appeared like a compiler issue; I think this global register
variable should be treated like a cmmon variable.

Maybe Matthew can shed some light on this?

  Ralf