Re: [Xenomai-core] __wrap_clock_gettime
On 2011-07-28 18:56, Jan Kiszka wrote: > On 2011-07-27 20:49, Gilles Chanteperdrix wrote: >> On 07/22/2011 05:04 PM, Jan Kiszka wrote: >>> Hi Gilles, >>> >>> pulling assert_context.c into the common libxenomai created a problem >>> around picking the right __wrap_clock_gettime. As libpthread_rt depends >>> on libxenomai, the latter is loaded first and defines the debug version >>> of __wrap_clock_gettime as the default. There is no chance to pull the >>> posix skin implementation. >>> >>> I don't have a nice idea yes how to resolve this. Options are: >>> - drop __wrap_clock_gettime from assert_context.c (affects any skin >>>user != posix) >>> - put assert_context stuff into separate library again >>> - put __wrap_clock_gettime in all skin libs != posix >>> >>> I'm favoring the simplest approach ATM, ie. the first one. Other ideas? >> >> I agree, but I would have thought __attriibute__((weak)) takes care of >> this issue. > > The point is that once you have pulled in that weak symbol into a > process, the dynamic loader won't update it if a non-weak version is > pulled in via dlopen. Fiddling with all options again, it turned out that the issue is also reproducible without any dlopen. This ordering is fine: -lpthread_rt -lxenomai This one does not work: -lxenomai -lpthread_rt Now the problematic ordering can be achieved in many ways, in our case by linking a top-level process first against a library with native+xenomai dependencies and then against one with pthread_rt+xenomai deps. That is resolvable by reordering, but only if you maintain this meta-information consistently (IOW, it's doomed to break accidentally again). So I've pushed a patch that replaces the code with a comment that explains the non-existence. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] __wrap_clock_gettime
On 2011-07-28 18:56, Jan Kiszka wrote: > On 2011-07-27 20:49, Gilles Chanteperdrix wrote: >> On 07/22/2011 05:04 PM, Jan Kiszka wrote: >>> Hi Gilles, >>> >>> pulling assert_context.c into the common libxenomai created a problem >>> around picking the right __wrap_clock_gettime. As libpthread_rt depends >>> on libxenomai, the latter is loaded first and defines the debug version >>> of __wrap_clock_gettime as the default. There is no chance to pull the >>> posix skin implementation. >>> >>> I don't have a nice idea yes how to resolve this. Options are: >>> - drop __wrap_clock_gettime from assert_context.c (affects any skin >>>user != posix) >>> - put assert_context stuff into separate library again >>> - put __wrap_clock_gettime in all skin libs != posix >>> >>> I'm favoring the simplest approach ATM, ie. the first one. Other ideas? >> >> I agree, but I would have thought __attriibute__((weak)) takes care of >> this issue. > > The point is that once you have pulled in that weak symbol into a > process, the dynamic loader won't update it if a non-weak version is > pulled in via dlopen. Mmh, maybe we have a fourth option: disabling the weak version if CONFIG_XENO_LIBS_DLOPEN is set. OTOH, the correlation may not be obvious to users. So that result could be even more confusing. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] __wrap_clock_gettime
On 2011-07-27 20:49, Gilles Chanteperdrix wrote: > On 07/22/2011 05:04 PM, Jan Kiszka wrote: >> Hi Gilles, >> >> pulling assert_context.c into the common libxenomai created a problem >> around picking the right __wrap_clock_gettime. As libpthread_rt depends >> on libxenomai, the latter is loaded first and defines the debug version >> of __wrap_clock_gettime as the default. There is no chance to pull the >> posix skin implementation. >> >> I don't have a nice idea yes how to resolve this. Options are: >> - drop __wrap_clock_gettime from assert_context.c (affects any skin >>user != posix) >> - put assert_context stuff into separate library again >> - put __wrap_clock_gettime in all skin libs != posix >> >> I'm favoring the simplest approach ATM, ie. the first one. Other ideas? > > I agree, but I would have thought __attriibute__((weak)) takes care of > this issue. The point is that once you have pulled in that weak symbol into a process, the dynamic loader won't update it if a non-weak version is pulled in via dlopen. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] __wrap_clock_gettime
On 07/22/2011 05:04 PM, Jan Kiszka wrote: > Hi Gilles, > > pulling assert_context.c into the common libxenomai created a problem > around picking the right __wrap_clock_gettime. As libpthread_rt depends > on libxenomai, the latter is loaded first and defines the debug version > of __wrap_clock_gettime as the default. There is no chance to pull the > posix skin implementation. > > I don't have a nice idea yes how to resolve this. Options are: > - drop __wrap_clock_gettime from assert_context.c (affects any skin >user != posix) > - put assert_context stuff into separate library again > - put __wrap_clock_gettime in all skin libs != posix > > I'm favoring the simplest approach ATM, ie. the first one. Other ideas? I agree, but I would have thought __attriibute__((weak)) takes care of this issue. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] __wrap_clock_gettime
Hi Gilles, pulling assert_context.c into the common libxenomai created a problem around picking the right __wrap_clock_gettime. As libpthread_rt depends on libxenomai, the latter is loaded first and defines the debug version of __wrap_clock_gettime as the default. There is no chance to pull the posix skin implementation. I don't have a nice idea yes how to resolve this. Options are: - drop __wrap_clock_gettime from assert_context.c (affects any skin user != posix) - put assert_context stuff into separate library again - put __wrap_clock_gettime in all skin libs != posix I'm favoring the simplest approach ATM, ie. the first one. Other ideas? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
