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 <[email protected]> wrote:
> 
> 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 <[email protected]> wrote:
>> Enabling semaphore-enabled probes system-wide requires poking
>> the semaphore’s memory in each process, I’m afraid. We can come
>> up with some implementation that would hook new process creation
>> and try to enable the semaphore when the relevant library gets loaded,
>> but it sounds a bit fragile. It could be interesting to explore
>> implementation alternatives for this. To hermetically enable the probe
>> we would need to synchronously block loading the provider’s library
>> into the target until we can modify the semaphore. This isn’t something
>> a BPF program can do, so it would require some external mechanism.
>> 
>>> On Jan 17, 2018, at 03:44, Kiran T <[email protected]> wrote:
>>> 
>>> Thanks Sasha, Yonghong.
>>> Looks like both php and python use semaphores.  Is it fundamentally
>>> not possible to enable this systemwide or is it a feature which hasn't
>>> been implemented?
>>> Maybe we get pids of the process as they hit another probe and then
>>> get the semaphore addresses and enable them?
>>> Or is there a way to start the processes with the semaphore enabled --
>>> a elf indicator or something?  Just thinking out loud.
>>> 
>>> Thanks,
>>> Kiran
>>> 
>>>> On Mon, Jan 15, 2018 at 10:30 PM, Sasha Goldshtein <[email protected]> 
>>>> wrote:
>>>> Please note that some USDT probes have an associated "semaphore",
>>>> which is really just a memory location that the probed code checks
>>>> before actually invoking the probe. You cannot enable USDT probes that
>>>> have a semaphore system-wide, without a process ID, because the
>>>> semaphore location has to be poked in each target process.
>>>> 
>>>> To see if your probes have an associated semaphore, just run tplist with
>>>> -v -v and it will print out the semaphore address for each probe. If it's
>>>> 0, you're good to do system-wide tracing.
>>>> 
>>>> Sasha
>>>> 
>>>> 
>>>> On Tue, Jan 16, 2018 at 8:08 AM Y Song via iovisor-dev
>>>> <[email protected]> wrote:
>>>>> 
>>>>> Kiran,
>>>>> 
>>>>> Yes, tracing through USDT without PID should work.
>>>>> You can just remove "-p" parameter and give a try.
>>>>> 
>>>>> Please try latest bcc as it fixed a few bugs.
>>>>> Let us know if you hit any issues.
>>>>> 
>>>>> Yonghong
>>>>> 
>>>>> 
>>>>> On Mon, Jan 15, 2018 at 5:11 PM, Kiran T via iovisor-dev
>>>>> <[email protected]> wrote:
>>>>>> I meant to say
>>>>>> 
>>>>>> Can one request to monitor binaries -- like with
>>>>>> uprobes/uretprobes but with USDT?
>>>>>> 
>>>>>>> On Mon, Jan 15, 2018 at 5:09 PM, Kiran T <[email protected]> wrote:
>>>>>>> Hi
>>>>>>> All the examples on tracing processes with USDT require the pid of the
>>>>>>> traced program:
>>>>>>> 
>>>>>>> https://github.com/iovisor/bcc/tree/master/examples/tracing
>>>>>>> 
>>>>>>> Can one not request to monitor binaries -- like with
>>>>>>> uprobes/uretprobes but with USDT?
>>>>>>> 
>>>>>>> I am trying to trace php scripts running on a webserver, and USDT
>>>>>>> would be ideal.  But, I won't have the pid of the process that will be
>>>>>>> spawned by the webserver in advance.
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Kiran
>>>>>> _______________________________________________
>>>>>> iovisor-dev mailing list
>>>>>> [email protected]
>>>>>> https://lists.iovisor.org/mailman/listinfo/iovisor-dev
>>>>> _______________________________________________
>>>>> iovisor-dev mailing list
>>>>> [email protected]
>>>>> https://lists.iovisor.org/mailman/listinfo/iovisor-dev
_______________________________________________
iovisor-dev mailing list
[email protected]
https://lists.iovisor.org/mailman/listinfo/iovisor-dev

Reply via email to