On 06/21/2017 10:14 AM, Rene Nielsen wrote: > Hi folks, > > Let me go straight into the problem: > We have a multi-threaded application that runs on a MIPS 24KEc using glibc v. > 2.24 under kernel v. 4.9.29 both compiled with gcc v. 6.3.0. > Our 24KEc has a 4-way 32 KBytes dcache (and similar icache), so it's prone to cache > aliasing (don't know if this matters...). > > We want to be able to do stack backtraces from a signal handler in case our > application makes a glibc call that results in an assert(). The stack > backtracing is made within the signal handler with calls to _Unwind_Backtrace(). > With the default set of glibc compiler flags, we can't trace through signal > handlers. Not so long ago, we used uclibc rather than glibc, and experienced the > same problem, but we got it to work by enabling the > '-fasynchronous-unwind-tables' gcc flag during compilation of uclibc. > Using the same flag during compilation of glibc causes unexpected runtime > problems: > > Many of the threads in our application call clock_gettime(CLOCK_MONOTONIC) many > times per second, so we greatly appreciate the existence and utilization of the > VDSO. > > Occassionally, however, clock_gettime(CLOCK_MONOTONIC) returns timestamps out of > order on the same thread. It's not that the returned timestamps seem wrong (they > are mostly off by some hundred microseconds), but they simply appear out of > order. > > Since glibc utilizes VDSO (and uclibc doesn't), my guess is that there's > something wrong in the interface between the two, but I can't figure out what. > Other glibc calls seem OK (I don't know whether there's a problem with the other > VDSO function, gettimeofday(), though). If not compiled with the infamous flag, > we don't see this problem. > > I have tried with a single-threaded test-app, but haven't been able to > reproduce. > > Any help is highly appreciated. Don't hesitate to asking questions, if needed. > > Thank you very much in advance, > Best regards, > René Nielsen Hi Rene I had a problem with the clock_gettime() call over VDSO on a MIPS BE 34Kc CPU, see this: https://www.linux-mips.org/archives/linux-mips/2016-01/msg00727.html It was sometimes off by 1 second. It is gone in the current version of LEDE (former OpenWrt), but when I used git bisect to find the place where it was fixed, I found a place which has nothing to do with MIPS internal or libc stuff. Makeing some pages uncached or flushing them help, but caused performance problems, I have never found the root cause of the problem. Hauke
