thiago added a comment.
In D14302#297159 <https://phabricator.kde.org/D14302#297159>, @jtamate wrote: > (gdb) disass > Dump of assembler code for function _ZN9QLockFile7tryLockEi: > 0x00007f54be8bc752 <+2>: mov $0xffffffff,%eax > ... > 0x00007f54be8bc76d <+29>: test %esi,%esi > ... > 0x00007f54be8bc772 <+34>: cmovs %eax,%esi > ... > 0x00007f54be8bc78c <+60>: movslq %esi,%rsi > 0x00007f54be8bc78f <+63>: callq 0x7f54be962150 <QDeadlineTimer::QDeadlineTimer(long long, Qt::TimerType)> > This is entirely correct: in +29 it checks parameter (in %esi) and in +34 if it has the sign bit set (read: is negative), moves -1 to it. Then it does a sign extension from 32- to 64-bit in +60, before placing the call. qMax is working properly. > Dump of assembler code for function _ZN16KDEInitInterface20ensureKdeinitRunningEv: > ... > 0x00007f54c0a23ae1 <+497>: xor %esi,%esi > 0x00007f54c0a23ae3 <+499>: mov %r12,%rdi > 0x00007f54c0a23ae6 <+502>: callq 0x7f54c0a1e960 <_ZN9QLockFile7tryLockEi@plt> Also correct: this passed a zero as the parameter to tryLock(). Now here's the interesting thing: > 0x00007f54c0a23aeb <+507>: test %al,%al > 0x00007f54c0a23aed <+509>: jne 0x7f54c0a23b8d <_ZN16KDEInitInterface20ensureKdeinitRunningEv+669> > 0x00007f54c0a23af3 <+515>: mov %r12,%rdi > 0x00007f54c0a23af6 <+518>: callq 0x7f54c0a1e9c0 <_ZN9QLockFile4lockEv@plt> > => 0x00007f54c0a23afb <+523>: mov %rbx,%rdi Note where the => is pointing to. It's not to the return from tryLock(), but to the return to lock(). We've been looking at the wrong line. That also means the patch doesn't make sense, because it's changing the line that is already working. REPOSITORY R271 KDBusAddons REVISION DETAIL https://phabricator.kde.org/D14302 To: jtamate, dfaure, #frameworks, thiago Cc: lvsouza, kde-frameworks-devel, michaelh, ngraham, bruns
