|
From: David F. <fa...@kd...> - 2013-01-18 20:41:28
Attachments:
hg_intercepts_qt5.diff
|
Trying to use helgrind with Qt5, I found out that it has special wrappers for Qt4 QMutex, which assume that the library is called libQtCore.so.*, but in Qt5 it's called libQt5Core.so.*, so new wrappers are needed. I made the attached simple patch, to add simple wrappers that call the Qt4 code. It works, mutexes are detected as such, but the backtraces end up with duplicated lines: ==9070== Lock at 0xD81F6F8 was first observed ==9070== at 0x4C3077F: QMutex::QMutex(QMutex::RecursionMode) (hg_intercepts.c:2186) ==9070== by 0x4C307A4: QMutex::QMutex(QMutex::RecursionMode) (hg_intercepts.c:2192) ==9070== by 0x585A9CE: QPostEventList::QPostEventList() (qthread_p.h:110) [...] Should I just duplicate the code of the wrappers instead? Or is there a more clever solution I'm missing? What I don't know is whether some implementations might should differ from the Qt4 implementation... -- David Faure, fa...@kd..., http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 |
|
From: Julian S. <js...@ac...> - 2013-01-23 11:25:19
|
> ==9070== Lock at 0xD81F6F8 was first observed > ==9070== at 0x4C3077F: QMutex::QMutex(QMutex::RecursionMode) (hg_intercepts.c:2186) > ==9070== by 0x4C307A4: QMutex::QMutex(QMutex::RecursionMode) (hg_intercepts.c:2192) > ==9070== by 0x585A9CE: QPostEventList::QPostEventList() (qthread_p.h:110) > [...] > > Should I just duplicate the code of the wrappers instead? > Or is there a more clever solution I'm missing? One alternative approach -- which doesn't really solve the problem, but which you might want to look at -- is to put the real code in a worker function and call that from all entry points. For example, see how sem_wait_WRK is used in hg_intercepts.c. That doesn't get rid of the second stack frame, but it does at least avoid the impression that there's some kind of strange recursion going on. Personally I quite like this scheme, in that it doesn't duplicate code. If you turned the __attribute__((noinline)) into __attribute__((always_inline)) then I think you'd get rid of the extra frame without having to duplicate the code by hand. > What I don't know is whether some implementations might should differ from the > Qt4 implementation... Right. That's the real problem. I don't think there's an easy way to figure this out, short of comparing the Qt4 and Qt5 implementations of the relevant functions. Once you have a patch you're satisfied with, I'd be happy to commit it. J |
|
From: David F. <fa...@kd...> - 2013-01-23 13:40:43
Attachments:
qt5_intercepts.diff
|
On Wednesday 23 January 2013 12:24:30 Julian Seward wrote: > > ==9070== Lock at 0xD81F6F8 was first observed > > ==9070== at 0x4C3077F: QMutex::QMutex(QMutex::RecursionMode) > > (hg_intercepts.c:2186) ==9070== by 0x4C307A4: > > QMutex::QMutex(QMutex::RecursionMode) (hg_intercepts.c:2192) ==9070== > > by 0x585A9CE: QPostEventList::QPostEventList() (qthread_p.h:110) [...] > > > > Should I just duplicate the code of the wrappers instead? > > Or is there a more clever solution I'm missing? > > One alternative approach -- which doesn't really solve the problem, but > which you might want to look at -- is to put the real code in a worker > function and call that from all entry points. For example, see how > sem_wait_WRK is used in hg_intercepts.c. That doesn't get rid of the > second stack frame, but it does at least avoid the impression that > there's some kind of strange recursion going on. Personally I quite > like this scheme, in that it doesn't duplicate code. OK. > If you turned the __attribute__((noinline)) into > __attribute__((always_inline)) then I think you'd get rid of the extra > frame without having to duplicate the code by hand. I tried, and it works, but it makes gcc warn: hg_intercepts.c:2048:13: warning: always_inline function might not be inlinable [-Wattributes] > > What I don't know is whether some implementations might should differ from > > the Qt4 implementation... > > Right. That's the real problem. I don't think there's an easy way to > figure this out, short of comparing the Qt4 and Qt5 implementations of > the relevant functions. Yeah. But in fact, the implementation of QMutex itself having changed, doesn't matter for helgrind's intercepts. The API is the same, so the expected behavior is the same, so helgrind can react the same. So I think we're fine for now. > Once you have a patch you're satisfied with, I'd be happy to commit it. Please find the patch attached. -- David Faure, fa...@kd..., http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 |