\chapter{Verification of Precompiled GOTO-Binaries}\label{chap:xmlbinaries}

It is often a tedious task to collect all the object files and libraries 
that a program needs to compile. To ease this task, a tool that mimics
the behaviour of gcc was implemented. It goes by the name \textsc{goto-cc}
and can replace gcc in makefiles. By doing so the result of the compilation
will be a 'binary' that contains the original program, transformed into a
GOTO-program and into XML format. All the compiling and linking can be done
using \textsc{goto-cc} and the result will usually be a single object or binary
file, that can easily be fed into a modelchecker like \satabs or \textsc{cbmc}.

\section{XML Binary Format}\label{sec:xmlformat}

In this section we will describe the format of the binary and object files, that
are generated by \textsc{goto-cc}.

The current implementation does not distinguish between an object file and a binary
file. Essentially those two types of files look the same, although a binary file 
would usually have a \textit{main} symbol and an according function, whereas an 
object file would not have these. The \textit{main} symbol is usually generated during compilation, when the language frontend recognizes the entry point of the program.

Every object file is then given in an XML format file. The root XML node is always
called \textsf{goto-object} and contains two sections: the symbol table and the 
function table.

\subsection{The Symbol Table}

The symbol table is the first child of the root XML node. It is contained within
an XML node called \textsf{symbols}, whereby for every symbol in the original
symbol table a child node of type \textsf{symbol} exists. These symbols have one argument (\textsf{name}) and up to four child nodes: a \textsf{type}, a \textsf{value}, some \textsf{flags} and a \textsf{location} (see fig. \ref{fig:xmlsymbols}).
\begin{figure}[hbtp]
\begin{verbatim}
<goto-object>
  <symbols>
    <symbol name="somename">
      <type>...</type>
      <value>...</value>
      <flags actual="false" ...>
        <mode>...</mode>
        <base_name>...</base_name>
        <module>...</module>
      </flags>
      <location>...</location>
    </symbol>
  </symbols>
  ...
</goto-object>
\end{verbatim}
\label{fig:xmlsymbols}
\caption{Structure of the XML symbol table}
\end{figure}
\begin{enumerate}
\item The \textit{type} of a symbol can contain a multitude of other subtypes and is therefore
represented by a direct translation of the original internal representation format of
\satabs.
\item The \textit{value} is an expression that gives the value of the symbol. The format of 
these expressions is the same as for the type, since \satabs uses the same internal
format for their representation.
\item The \textit{flags} section consists of 13 boolean attributes and three child nodes containing strings. The 13 boolean attributes are actual attributes of the \textsf{flags} XML node and are named
by these constants: \textsf{actual}, \textsf{axiom}, \textsf{binding}, \textsf{extern},
\textsf{free\_var}, \textsf{input}, \textsf{lvalue}, \textsf{macro}, \textsf{output},
\textsf{statevar}, \textsf{static}, \textsf{theorem} and \textsf{type}. The three child nodes
are: the \textsf{mode}, which gives the mode used to compile the original file (i.e. the language frontend being used), the \textsf{base\_name}, which is just the basic and short name of the symbol without any scope identifieres, and the \textsf{module}, which gives the name of the source file (without extension) that the symbol was defined in. 
\item The \textit{location} node gives the location of the definition of the symbol, as
a reference to the original code files. It is a direct translation of the internally used
format as well, but in the current implementation these location elements always look the same:
The contain up to four childs elements of type \textsf{named\_sub}, each given an attribute \textsf{name}. Each of those elements then contains another child element of type \textsf{id}, that in turn contains string data. The four different named\_sub's names are \textsf{file} (the source file with a relative path to it), \textsf{function} (the scope in which the symbol occurs), \textsf{line} and \textsf{column} (the exact location of the definition). For cleanliness any of these four elements must be allowed to be missing, since sometimes those values can not be given correctly.
\end{enumerate}
\textbf{Warning:} \textit{The above information is subject to change in the near future. A hashtable implementation will be used to be able to share symbols (like for subtypes) between other symbols. This will greatly reduce the size of the resulting object files, but will also rearrange the whole format.}
\textbf{Note:} \textit{A library to parse the XML binaries will of course be provided as soon as possible. Current versions of \satabs and \textsc{CBMC} already feature a command line option that enables them to read the binaries described in this section (--xml-binary)}

\subsection{The Function Table}

After the \textsf{symbols} element, there follows an XML node named \textsf{functions}.
This node contains the function table, i.e. all implemented functions and their code
in GOTO-program form. Every function consists of a set of instructions, whereby 12 different instruction types are known and described below. They all feature an XML node of the same type as their name, and can but do not have to contain these two child nodes: 
\begin{enumerate}
\item[\textsc{location}] giving the source code location of the instruction
\item[\textsc{variables}] giving the variables being seen (not necessarily used) by the instruction.
\end{enumerate}
\begin{figure}
\begin{verbatim}
<goto-object>
  ...
  <functions>
    <function name="somename">
      <instruction>...</instruction>
      <goto>...</goto>
      <assume>...</assume>
      ...
    </function>
  </functions>
</goto-object>
\end{verbatim}
\label{fig:xmlfunctions}
\caption{Structure of the XML function table}
\end{figure}
If an instruction is being jumped to by a GOTO instruction somewhere else in the program, then the instruction will need a label. This is implemented as a numerical attribute of the instruction node, that goes by the name \textsc{targetlabel}.

It follows a list of known instruction types and their description:
\begin{enumerate}
\item[goto] Conditionally jumps from the current instruction to another. An additional element named \textsc{guard} describes the condition in the form of an expression (see the \textsc(value) element of symbols for a description of expressions in this format).
\item[assume] Used to add predicates. This instruction features an added \textsc{guard} just like \textsc{goto}.
\item[assert] See \textsc{assume}. 
\item[skip] An empty instruction.
\item[end\_function] This instruction does not contain any elements. It is used to mark the end of a function.
\item[location] Handled like \textsc{skip}.
\item[sync] Currently not in use.
\item[atomic\_begin] Currently not in use.
\item[atomic\_end] Currently not in use.
\item[instruction] Any other instruction. Instructions of this type have an additional \textsc{code} child element that contains the instruction code. This code is translated
directly from the internal representation.
\item[start\_thread] Currently not in use.
\item[end\_thread] Currently not in use.

\end{enumerate}