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