> -----Original Message----- > From: David Daney [mailto:ddaney.cavm@xxxxxxxxx] > Sent: 09 January 2015 23:53 > To: Daniel Sanders > Cc: Sergei Shtylyov; linux-mips@xxxxxxxxxxxxxx; Ralf Baechle; Paul Burton; > Markos Chandras; James Hogan; Behan Webster > Subject: Re: [PATCH] MIPS: Changed current_thread_info() to an equivalent > supported by both clang and GCC > > On 01/09/2015 12:06 PM, Daniel Sanders wrote: > >> -----Original Message----- > >> From: David Daney [mailto:ddaney.cavm@xxxxxxxxx] > [...] > > > > >>>>> Signed-off-by: Daniel Sanders <daniel.sanders@xxxxxxxxxx> > >>>> > >>>> [...] > >>>> > >>>>> diff --git a/arch/mips/include/asm/thread_info.h > >>>> b/arch/mips/include/asm/thread_info.h > >>>>> index 99eea59..2a2f3c4 100644 > >>>>> --- a/arch/mips/include/asm/thread_info.h > >>>>> +++ b/arch/mips/include/asm/thread_info.h > >>>>> @@ -58,11 +58,11 @@ struct thread_info { > >>>>> #define init_stack (init_thread_union.stack) > >>>>> > >>>>> /* How to get the thread information struct from C. */ > >>>>> +register struct thread_info *current_gp_register asm("$28"); > >>>> > >>>> *static* missing? > >>>> > >>>> WBR, Sergei > >>> > >>> Combining 'register' and 'static' is invalid. > >> > >> Defining global variables in header files is also invalid. > > > > I agree with that statement but named register globals are not the same as > normal global variables. In particular, they do not take up space in the data > section and they do not have an entry in the symbol table. They can therefore > be included in multiple objects without causing link errors. > > > > Well, the GCC manual seems to bless your usage, so I withdraw my > objection on making this global. But, changing the name to > "current_gp_register" removes information about what it is used for. > > Can you resend that patch so that it still has the name > "__current_thread_info", and only moves it to the global scope? > > Thanks, > David Daney Sure. I'll Cc you directly on the re-send. The main reason I renamed it is that identifiers starting with '__' are reserved. It's pretty unlikely but it's possible that the name will conflict with a C implementation in the future.
