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
