RE: Oprofile JIT Code Proposal - Part 2

[Yeh, J. <jas...@am...>]

John,

The original proposal dealt mostly with data processing.  This email is
aimed to give a high level of the proposed changes on post-processing.

Here are some relevant information from the part 1 of the proposal:
1. Sample files of JITted code are stored in
/var/lib/oprofile/samples/{jit}/<tgid>/<start address>-<rejit
count>/<Oprofile Sample file name>
2. Native code written by the daemon using libbfd is stored in
/var/lib/oprofile/jit/<tgid>/<start address>-<rejit count>
3. Images that has JITted code as dependent will have such entry
.../{dep}/{jit}/<tgid>/<address>-<rejit count>/...

<rejit count> is from 0 to 0xFF, or an arbitrary limit.
<Oprofile Sample file name> is regular Oprofile sample file name, such
as CPU_CLK_UNHALTED.100000.0.all.all.0.

Post-process for sampling generally goes through the follow steps:
1. Generate list of sample file, done by "generate_file_list()"
2. Classify sample files, done by "arrange_profiles()"
3. Invert sample files, done by "invert_profiles()"
4. Processing the binary file and sample file, done by
"populate_for_image()"

Steps 1 to 3 requires minimal changes. The code needs to be aware of
JITted sample files and binary files.  Currently in step 4, binary files
are manipulated by op_bfd.  Since a conceptual binary module of JITted
code is actually a number of binary files, each consists of a function.
I propose to create a new interface which would contain a list or array
of the current op_bfd.  In addition to the current functionality, the
new interface would aggregate all JITted binary files in to one
conceptual JITted module.  If the interface is being used on a regular
binary file, it would contain only one op_bfd and act as it is now.
Similar changes are also need in order for summary to interpret JITted
module correctly.  Please let me know if the explanation is not clear.

Jason