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 _______________________________________________ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers