<div dir="ltr"><div>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?</div><div><br></div><div>My understanding is that at initialization, the generated log file should contain:</div><div>[File header with pid][metadata record containing pid and tid]</div><div><br></div><div>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?</div><div><br></div><div>For now, what would be the best way to test the new format to make sure the format has the correct values?</div><div><br></div><div>Thanks</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 27, 2018 at 11:29 PM, Dean Michael Berris <span dir="ltr"><<a href="mailto:dean.berris@gmail.com" target="_blank">dean.berris@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
> On 28 Jun 2018, at 07:28, Henry Zhu <<a href="mailto:henryzhu@seas.upenn.edu">henryzhu@seas.upenn.edu</a>> wrote:<br>
> <br>
> Thanks, that cleared up my confusion about version numbers.<br>
> <br>
> I've implemented the handlers and done up to 6) below. I'm unsure of how to test what I have added.<br>
> <br>
> 1) Update the Header.Version = 3 (from 2)<br>
> 2) Add a new XRayRecord for pid (XRayPidRecord) in xray_basic_logging.h<br>
> 3) Implement InMemoryRawLogWithPid similar to how InMemoryRawLogWithArg is implemented<br>
> 4) Implement __xray_set_handler_pid<br>
> 5) call __xray_set_handler_pid, passing in basicLoggingHandlePid in the initialization function for basic mode<br>
> 6) Add an assembly stub for the [od handler<br>
> <br>
<br>
</span>Huh, I’m sorry for not being clear here — I suspect you don’t need steps 3 to 6.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<span class=""><br>
> 7) Add additional parsing for pid for llvm-xray tool to parse the header for pid and xray entries for pid<br>
> <br>
> 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?<br>
<br>
</span>Please see above.<br>
<span class=""><br>
> Q2. Should the PID always be set in the file header when xray starts?<br>
<br>
</span>Yes.<br>
<span class=""><br>
> Q3. How do I run test cases? <br>
<br>
</span>There’s a ‘check-all’ and ‘check-xray’ target when you build LLVM+Clang+compiler-rt.<br>
<span class=""><br>
> Q4. Would it be possible to always call the pid logger when fork is called?<br>
> <br>
<br>
</span>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.<br>
<br>
Cheers<br>
<span class="HOEnZb"><font color="#888888"><br>
-- Dean<br>
<br>
</font></span></blockquote></div><br></div>