Just checked python (built from source with --with-dtrace) USDT semaphores:
[yhs@localhost bin]$ nm python3 | grep semaphore
008eb52c d python_function__entry_semaphore
008eb52e d python_function__return_semaphore
008eb53c d python_gc__done_semaphore
008eb53a d
yep. uprobe is always 'int 3' so far, since kernel needs to take control.
we can add something like writing arbitrary value as long as that
address is in the file
and accessed via inode. If semaphore is in bss then kernel changes
would be required.
I hope we can try such approach without changing
You’re saying that the uprobe installation will replace the semaphore value
with something non-zero? Is that guaranteed? If using “int 3” then probably yes
but if using an optimized jump? And will it work on non-x86?
> On Jan 17, 2018, at 17:05, Alexei Starovoitov
I think it should be possible to abuse uprobe kernel logic to flip the
semaphore value.
Instead of writing into /proc/pid/mem we can uprobe on that exact location.
Though it's not text, but data section. It may work ?
On Wed, Jan 17, 2018 at 8:57 AM, Sasha Goldshtein via iovisor-dev
Not sure I understand your proposal re the kernel setting the semaphore.
Anyway, yes, the semaphore concept and implementation goes back to SystemTap
SDT which is basically DTrace probes.
> On Jan 17, 2018, at 16:55, Kiran T wrote:
>
> Is this because this is tied to
Is this because this is tied to DTRACE abi? Perhaps another elf note
or comment could be implemented, so this semaphore is set on binary
load itself by the kernel? Again thinking out loud :)
Thanks,
Kiran
On Tue, Jan 16, 2018 at 8:51 PM, Sasha Goldshtein wrote:
> Enabling