MIPS Creator CI20 patches (again)

[Paul Boddie]

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.

Paul