>jalvo@cloud9.net (John G. Alvord) writes:
>> I've done some work on a system, based on CPP output. It certainly
>> makes parsing easier with respect to conditional macros and includes.
>> One use was creating an exact dependency file when the compiler in use
>> didn't support that output.
>Hum. Do you mean you did something like gcc -MM or Linux' mkdep,
>or did you actually maintain a faithful model of cpp conditionals and macros?
I was using a compiler (SAS/C) which did not have anything like a -MM
option. I ran CPP with the same controls (defines/include directories)
as the compiler used. I processed the resulting CPP output file with a
PERL program which calculated which include files were used.
Actually, the first time I did it (in REXX, OS/2I was to generate a
running display of which files were included at each time. I knew a
particular file was included, but I couldn't figure out why. With a full
running report of the include situation at each point, it was easy.
Later on, I rewrote it in PERL(AIX) and gave it an option to generate an
analogue of the gcc -MM .u file.
Linux' mkdep generates a superset of the actual dependencies; it works
great for the purpose and it also quite fast... it just isn't accurate.
>
>> For generating a call graph, one tough parts involves function calls via
>> indirect lookup and use of tables of function addresses.
>I believe the stalin whole-program optimizing compiler for Scheme
>does it well already. The problem I see when adapting this technology
>to the Linux kernel, is the possibility of dynamic module insertion,
>that must be made expressible (and expressed) to the analyzer.
>
Dynamic module insertion is another interesting aspect.
john alvord
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html