MIPS Creator CI20 patches (again)
adam at os.inf.tu-dresden.de
Wed Jan 10 00:48:03 CET 2018
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:
> 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
> - 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
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.
More information about the l4-hackers