Re: Instrumenting code for profiling. (Nick Maclaren)
26 Nov 2004 22:42:25 -0500

          From comp.compilers

Related articles
Instrumenting code for profiling. (2004-11-14)
Re: Instrumenting code for profiling. (glen herrmannsfeldt) (2004-11-17)
Re: Instrumenting code for profiling. (2004-11-17)
Re: Instrumenting code for profiling. (2004-11-19)
Re: Instrumenting code for profiling. (2004-11-20)
Re: Instrumenting code for profiling. (Ira Baxter) (2004-11-20)
Re: Instrumenting code for profiling. (2004-11-20)
Re: Instrumenting code for profiling. (2004-11-26)
| List of all articles for this month |

From: (Nick Maclaren)
Newsgroups: comp.compilers
Date: 26 Nov 2004 22:42:25 -0500
Organization: University of Cambridge, England
References: 04-11-043 04-11-051 04-11-065 04-11-088
Keywords: performance, debug
Posted-Date: 26 Nov 2004 22:42:25 EST

Michael Tiomkin <> 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

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

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:

     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>;
        {++count_table[<statement number>]; a = <expression>;}

Nick Maclaren.

Post a followup to this message

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