I detected this in my dmesg : [Xenomai] bad syscall <0xf0002>
The message isn't associated to any crash. It doesn't seem to break anything, but it doesn't smell good... does it ? It happens each time I dlopen a cobalt-wrapped shared object (also happens if just using alchemy, without any other special linker instuctions). I was looking at kernel/cobalt/posix/syscall*, but still I couldn't figure out what is emitting that wrong syscall when dlopening. In case it matters, OABI compatibility is not enabled in my build, and target is an imx28. I'm a bit lost. Where should I search ? On 27/04/2018 17:43, Philippe Gerum wrote: > On 04/27/2018 04:43 PM, Edouard Tisserant wrote: >>> Now let see if dlopen/dlclose some code using alchemy segfaults or not... >> Well, it didn't work as-is, but I finally got it working ! >> >> If I was dlopening anything relying on copperplate after that python >> code, then it was making an assert : __register_setup_call: Assertion >> `!main_init_done' failed. >> >> The reason is that all xenomai libraries we plan to use have to be >> loaded _before_ call to xenomai_init, so that their setup call is >> registered. >> >> Hereafter is updated (and simplified) python code : >> >> from ctypes import * >> for name in ["cobalt", "modechk", "copperplate", "alchemy"]: >> globals()[name] = CDLL("lib"+name+".so", mode=RTLD_GLOBAL) >> cobalt.xenomai_init(pointer(c_int(0)), >> pointer((POINTER(c_char)*2)(create_string_buffer("python"), None))) >> >> Note : Order of dlopen matters. Argument passed to >> xenomai_init(&argc,&argv) are here only to prevent de-referencing NULL. >> >> After this being executed, you can load and unload many shared object >> that use alchemy and posix (they should not be linked to boostrap_pic.o) >> > Looks good. The key point is that xenomai_init() is the call from the > API which controls the whole Xenomai init process, after which Xenomai > libs are fully functional. This explains why any library which wants to > be part of that process needs its setup descriptor to be known and > registered prior to issuing this call. > > The bootstrap module is just a helper that calls xenomai_init() > automatically before the main() routine is entered (bootstrap.o) when > glued to a final executable, or right after a DSO is loaded > (bootstrap-pic.o) when glued to a shared library. If the application > wants a fine-grained control over the init sequence instead, it just > needs not to include the bootstrap module in the executable/DSO, calling > xenomai_init() manually when it sees fit. > _______________________________________________ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai