On Wed, 5 Dec 2007, Adam Leventhal wrote:
> On Wed, Dec 05, 2007 at 06:19:58PM +0100, [EMAIL PROTECTED] wrote:
>> Thanks, Adam, even though this is unfortunate. If function pointer calls in
>> C code can break pid provider this is a severe limitation on its usability.
>> I would say any non-trivial C program makes use of function pointers ...
>
> I'm not sure I agree with that, but fair enough.
Well, it may be acceptable, but then it should be documented at least.
I filed doc change request ---> #6638313
>
>> curiously there appears to be no jump table in the output (attached) of
>>
>> # dis -F sge_mirror_process_event_list ./sge_mirror.o
>
> Here is it:
>
>> sge_mirror_process_event_list+0xdf: 41 ff e0 jmp *%r8
Ok.
>
>> Any thoughts?
>
> What you could do is explicictly place a probe on the addresses of the return
> sites (just sge_mirror_process_event_list+0xf1a fortunately):
>
> # mdb /usr/bin/date
>> main::dis ! grep ret
> main+0x1c5: ret
>> main+0x1c5=K
> 80511e9
>> ^D
> # dtrace -c date -n 'pid$target::-:80511e9{ printf("%A", uregs[R_PC]); }'
> dtrace: description 'pid$target::-:80511e9' matched 1 probe
> Wed Dec 5 11:02:57 PST 2007
> dtrace: pid 177209 has exited
> CPU ID FUNCTION:NAME
> 1 88849 -:80511e9 date`main+0x1c5
>
> Of course: be careful with the explicit address syntax, and be sure you
> don't put a probe on an address which isn't at the start of an instruction.
Thanks. Placing the probe at the adress of the return is not practical for
us as the Dtrace monitor is delivered with SGE to CUs. I guess we will solve
the issue by wrapping function pointer contaminated
sge_mirror_process_event_list()
with some other function and probe the wrapper instead.
Regards,
Andreas
_______________________________________________
dtrace-discuss mailing list
[email protected]
