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