A case against standards

Armin Rigo arigo@tunes.org
Tue Nov 4 05:29:02 2003


Hello Ilmari,

On Tue, Nov 04, 2003 at 01:21:47AM +0200, Ilmari Heikkinen wrote:
> > This is not always possible;  
> > optimizations that cannot be undone correspond to the inference engine not
> > finding a way to decode it using the available set of operations.  This is a
> > useful piece of information in itself, because it can be used e.g. to prevent
> > the compiler from doing some optimizations when the user (or some other
> > program) wants the ability to inspect the result.
> 
> One way might be to have the compiler build two programs, the other the
> semantically sparse imperative binary and the other a program to map the
> binary to the source code. A debugger made for specifically the program.

Yes, a lot of things could be done indeed.  My point here was rather to try
and see how the view I am developping relates to and eases comprehension and
implementation of particular problems.  You can indeed write a compiler that
writes a full debugger library alongside the binary program; I was trying to
see if we could ease the job of the compiler instead of making it more complex
:-)

Your suggestion is code-only non-declarative debugging information.  We
currently have data-only declarative debugging file formats.  Instead, look at
compilation and decompilation as just conversion routines, able to use a full
range of formats and conversion tools: from the most standard ones ("this
position in the stack frame corresponds to that signed int local variable") to
the most custom ones ("at this point, if register EAX is less than EBX+100,
then it means that this data structure in the source program was optimized
away, but it could be reconstructed in such and such way").

In general I am trying to separate two aspects: the program in the algorithmic
sense written in some formal language (could be processor machine code), and
extra information about it capturing the existence and relationships of some
implicit semantic aspects (typically not machine code -- it is much more
natural for compilers to produce this extra information declaratively at a
high level; but then it could possibly be itself compiled down to machine code
to make an efficient debugger, which is useful though probably not for
interactive debugging).


A bientot,

Armin.