[llvm-dev] XRay feature – pid reporting
Henry Zhu via llvm-dev
llvm-dev at lists.llvm.org
Thu Jun 28 14:18:55 PDT 2018
I'm still somewhat unclear about what you mean by "metadata record entry at
the beginning of the block". I understand that I can make a MetadataRecord
that contains the pid/tid since a metadata record contains 16 bytes.
However, I don't understand what do you mean by the "beginning of the
block". Do you mean right after the file header?
My understanding is that at initialization, the generated log file should
[File header with pid][metadata record containing pid and tid]
Updating handlers to fetch the PID and TID directly can be done. However,
XRayRecord and XRayArgRecord do not have PID fields, Do I replace some of
the padding with the PID field, or should I make another XRayPayload
containing the TID/PID?
For now, what would be the best way to test the new format to make sure the
format has the correct values?
On Wed, Jun 27, 2018 at 11:29 PM, Dean Michael Berris <dean.berris at gmail.com
> > On 28 Jun 2018, at 07:28, Henry Zhu <henryzhu at seas.upenn.edu> wrote:
> > Thanks, that cleared up my confusion about version numbers.
> > I've implemented the handlers and done up to 6) below. I'm unsure of how
> to test what I have added.
> > 1) Update the Header.Version = 3 (from 2)
> > 2) Add a new XRayRecord for pid (XRayPidRecord) in xray_basic_logging.h
> > 3) Implement InMemoryRawLogWithPid similar to how InMemoryRawLogWithArg
> is implemented
> > 4) Implement __xray_set_handler_pid
> > 5) call __xray_set_handler_pid, passing in basicLoggingHandlePid in the
> initialization function for basic mode
> > 6) Add an assembly stub for the [od handler
> Huh, I’m sorry for not being clear here — I suspect you don’t need steps 3
> to 6.
> You may just need to add a metadata record at the beginning of the block,
> and getting the PID and TID directly (instead of the cached versions). This
> way FDR mode will have the PID record and the TID records at the beginning
> of the block.
> For Basic Mode we need to get the TID directly instead of using the cached
> version, and also to get the PID directly instead of attempting to cache
> it. This would be an update in the handlers.
> In Profiling Mode this would be a little tricky, because it may need
> changes in more places. I need to think about that I little more.
> > 7) Add additional parsing for pid for llvm-xray tool to parse the header
> for pid and xray entries for pid
> > Q1. For 7), on order to log the pid, one would need to patch the
> function to call the pid logger. Should I add an attribute to clang that
> patches the function, so that the function calls the pid? Or is there an
> easier way to test the functionality of the pid logger?
> Please see above.
> > Q2. Should the PID always be set in the file header when xray starts?
> > Q3. How do I run test cases?
> There’s a ‘check-all’ and ‘check-xray’ target when you build
> > Q4. Would it be possible to always call the pid logger when fork is
> Unfortunately no. The simpler solution would be to update the handlers to
> get the PID alongside the TID, and to always get the TID instead of using a
> cached version.
> -- Dean
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev