MIPS Creator CI20 patches (again)

[Adam Lackorzynski]

On Tue Jan 09, 2018 at 23:17:10 +0100, Paul Boddie wrote:
> On Tuesday 9. January 2018 01.02.58 Paul Boddie wrote:
> > 
> > So, I am assuming that the compiler gets confused by the freestanding
> > assembly language definition of the function, and the object goes missing
> > in some way that then leads to the error. Of course, the above introduces
> > other operations that are superfluous, but perhaps not harmful, due to the
> > general boilerplate included in C-level functions.
> > 
> > Anyway, I'll see if I get any response from the other discussion.
> 
> Well, I got a response that effectively describes the cause of the problem:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884821#25
> 
> As I understand it, the assembly language code defines a local object (the 
> default behaviour), but the C compiler regards it as a global object due to 
> the declaration used:
> 
> void __attribute__((visibility("internal"))) thread2(void);
> 
> Consequently, the linker complains about this inconsistency (but also seems to 
> experience an error generating the error message).
> 
> What I see from the mybuild/include/mips/l4/util/thread.h file are two macros 
> for defining and declaring thread functions:
> 
> - L4UTIL_THREAD_FUNC introduces a global object wrapping the actual function
> 
> - L4UTIL_THREAD_STATIC_FUNC introduces a local object wrapping the actual 
> function, declaring it at the C level as a global, internal object
> 
> Since we are dealing with the output of the latter macro, it seems that there 
> are two main alternatives that suppress the error:
> 
> - Add a ".global" directive for the introduced wrapper object in the assembly 
> language (as is done by the former macro), producing a global but internal 
> object
> 
> - Declare the object at the C level as a static object, as in...
> 
>   static void thread2(void);
> 
> Another solution could involve using a C-level wrapper function and including 
> assembly language inside that, if necessary. Maybe someone (Sarah?) could say 
> what the motivations were for doing it in the current way. My hypothesis is 
> that extra instructions get generated for the C functions that are either 
> superfluous or harmful, such as accessing the stack, but I would gladly be 
> corrected.

Adding the .global to the asm block makes thread2 a global symbol which
I'd like not to have here (contrary to L4UTIL_THREAD_FUNC). Just doing
"static void thread2()" gives warnings because there is no
implementation. Looks to me that having a function is much better here.
I'll have a look into this.

Thanks for investigating this. And also thanks to James for the nice
explanation of the issue.



Adam