We haven't yet described how we process the absolute PC value into something usable by the user-space daemon. When we find a sample entered into the CPU buffer, we traverse the list of mappings for the task (remember, we will have seen a task switch earlier, so we know which task's lists to look at). When a mapping is found that contains the PC value, we look up the mapped file's dentry in the dcookie cache. This gives the dcookie ID that will uniquely identify the mapped file. Then we alter the absolute value such that it is an offset from the start of the file being mapped (the mapping need not start at the start of the actual file, so we have to consider the offset value of the mapping). We store this dcookie ID into the event buffer; this identifies which binary the samples following it are against. In this manner, we have converted a PC value, which has transitory meaning only, into a static offset value for later processing by the daemon.

We also attempt to avoid the relatively expensive lookup of the dentry cookie value by storing the cookie value directly into the dentry itself; then we can simply derive the cookie value immediately when we find the correct mapping.