4 ms·
>>> frame 5 #5 0x00007f7430627733 in pthread_mutex_lock () from /home/rusty/futex/sysroot/lib/x86_64-linux-gnu/libpthread.so.0 >>> disassemble pthread
by WirelessGigabit 3y ago
>>> frame 5
#5 0x00007f7430627733 in pthread_mutex_lock () from /home/rusty/futex/sysroot/lib/x86_64-linux-gnu/libpthread.so.0
>>> disassemble pthread_mutex_lock
...
0x00007f7430627723 <+211>: mov %rdi,0x8(%rsp)
0x00007f7430627728 <+216>: and $0x80,%esi
0x00007f743062772e <+222>: call 0x7f743062efc0 <__lll_lock_wait>
=> 0x00007f7430627733 <+227>: mov 0x8(%rsp),%rdi
0x00007f7430627738 <+232>: jmp 0x7f7430627689 <pthread_mutex_lock+57>
...
>>> x/w ($rsp + 8)
0x7f7371ff1ce8: 0x08001ea1
I love reading these articles, but sometimes they skip over things that the reader might not understand.
In my case I don't understand where x and w come from, and how the result of 0x08001ea1 is invalid (I can see it's not aligned to a 4 byte boundary).
- enoent 3y agox/w is a gdb command to dereference and print (x) 1 word-sized data (w) at the address given by the expression. So 0x08001ea1 was the unaligned address stored at $rsp + 8, passed as argument to __lll_lock_wait.