Re: A few notes on how I see the whole process working.

["Alexey Zaytsev" <alexey.zaytsev@gmail.com>]

On Fri, Apr 25, 2008 at 12:15 AM, Alexey Zaytsev
<alexey.zaytsev@gmail.com> wrote:

[...]

>  >  >                 - (maybe something else I've missed?)
>  >
>  >  Most of the things in a sparse "struct symbol" would probably prove
>  >  useful, I suspect.
>  >
>  May be. I'm still not really familiar with the sparse internals.

I still don't buy the bytecode idea, but it seems that the macros are
not actually lost after being pre-processed, which was my main concern
against even thinking about dumping the sparse internal representation
into the generated sparse object files. Still wandering in the dark. Will
look closed when return.

>
>
>  >  Eventually we will probably want something like the linearized
>  >  bytecode.
>  >
>
>  While I generally agree the we need to do something like
>
>  sparse -> intermediate data -> checker
>
>  the intermediate format is a bit unclear to me. It has to be verbose
>  enough to loose no essential information, and still be practical.
>  If by linearized bytecode you mean something like what we get
>  running sparse -ventry, this is clearly not going to work. As an
>  example, suppose you wish to check that local_irqsave() and
>  local_irqrestore() are balanced. This means, the checker actually
>  wants to look at the original source code, not even at the
>  pre-processed C code.
>
>  So, suggestions on the intermediate format are welcome.
>