Re: Instrumenting code for profiling.

Michael Tiomkin <tmk@netvision.net.il> wrote:
>
> Well, with some natural assumptions, you don't need to do full
>parsing for C profiling. You can use the line info in the executable
>to find the images of the "statements" (BTW, the line num/file name
>can be used as an ID for a statement). In C, the only problem can be
>jump tables in switch statements, but you can find the pattern that
>your compiler uses and update the jump tables as well.
>
> For a function with one entry (the case of C), it's not very
>complicated to make a copy of the function extended with
>instrumentation. You even don't neeed to analyze the executable: a
>good disassembler can help in this task, and then you can easily
>insert profiling instructions.


Well, the original posts were referring to inserting profiling in the
source, but in fact my remarks apply to both, for similar but unrelated
reasons.


Your 'solution' doesn't work in general, for a great many reasons,
including (but not limited to):


        The mapping between statements and lines can be very unclear,
ambigous and even meaningless, especially when the preprocessor is
used heavily.


        The mapping between statements and locations is the code is much
the same if any optimisation is used, especially global optimisations
such as inlining.


        There may be no disassembler that generates compilable code, nor
even any documentation - even if there is, its output may need
reverse engineering to insert instructions.


        There is often not even any documentation on the exact output
format produced by the compiler.


> The question is if you really need to do profiling by yourself. Most
>compilers would happily do this for you, and there are other tools
>that do profiling for executables, like Vtune of Intel did for Win/x86
>platform.


The original poster was asking about how to write such a tool, and
the answer is that you have to write a partial parser for Fortran,
BCPL etc., but effectively a full one for Algol 68, C etc.


In the case of C, you need a full preprocessor stage to extract the
actual statements, and even then inserting code can have some subtle
effects on the code surrounding it. In C90, the main problem was
to do with whether blocks contained declarations, but C99 has added
delightful little "gotchas" like:


              6.5.2.5 Compound literals


              [#6] The value of the compound literal is that of an unnamed
              object initialized by the initializer list. If the compound
              literal occurs outside the body of a function, the object
              has static storage duration; otherwise, it has automatic
              storage duration associated with the enclosing block.


No, you can no longer replace:
        a = <expression>;
by:
        {++count_table[<statement number>]; a = <expression>;}




Regards,
Nick Maclaren.

Return to the comp.compilers page.
Search the comp.compilers archives again.