Diablo

A managed class is a basic class with the additional feature that it allows for dynamic members. We will limit this discussion to the extensions to the basic class. An explanation of that mechanism can be found elsewhere.

#include <diablosupport_class.h>
#ifndef CLASS
#define CLASS ins
#define ins_field_select_prefix INS
#define ins_function_prefix Ins

#define MANAGER_TYPE t_cfg *
#define MANAGER_NAME cfg
#define MANAGER_FIELD ins_manager

This section will provide you with a high-level overview of the most important Diablo data structures.

We will introduce the concept of a basic class through an example:

#include <diablosupport_class.h>
#ifndef CLASS
#define CLASS ins
#define ins_field_select_prefix INS
#define ins_function_prefix Ins

We define a new class ins. This will result in a new type t_ins. The ins_field_select_prefix will be used in the getters and setters. The ins_function_prefix will be used in functions.

DIABLO_CLASS_BEGIN
EXTENDS(t_relocatable)

The class ins is an extension of the class relocatable. As such, it will inherit the getters, setters and non-private functions of the class relocatable. We will come back to this later.

Diablo provides a class mechanism which enables:

• automatic generaton of getters and setters
• inheritance

And in the case of managed class:

• dynamic members

As such we make a distinction between a basic class and a managed class .

The dynamic member mechanism enables the extension of a managed class with an additional member. Many analyses require members which may not be part of the core class. To solve this problem, the dynamic member mechanism can be used.

A number of steps are needed to enable the usage of the member:

1. An instance of the type t_dynamic_member_info needs to be defined to keep track of the new member
2. An Init, Fini and Dup function need to be written to define the behaviour when an instance of the class is created, killed or duplicated

These slides give a high level overview of how to add the necessary support for a new architecture to Diablo. Porting Diablo to a new architecture it not trivial, but with some help of the diablo developers it is certainly doable. If you have plans to port Diablo to a new architecture, please let us know.

I've added a more recent patch file that can be applied to binutils 2.16.1
It has only be tested partially, since we have had some trouble in building a recent patched toolchain. We would be happy to find out if anyone has been able to build a patched toolchain using gcc 4.0, glibc 2.3.5 or newer tools. You can download the new patch file from the download page or directly from here.

You still need to patch the compiler when using uclibc or in case you use glibc, you'll have to patch glibc.

When Lancet displays the control flow graph of a function, it sometimes occurs that the graph is not connected.
There are two possible reasons for this:

1. The most obvious reason is that there are in fact basic blocks with no incoming edges. When performing unreachable code elimination, these blocks should disappear.
2. The control flow graph contains an interprocedural edge that is not a CALL edge. An example of this is given in the figure below. In the case of regular function calls, we draw a red arrow from the call site to the called function (yellow box below) and a blue arrow from the called function (yellow box) to the return site. In this case, control flow is not so clean, because when function _IO_vfprintf_5 is entered via basic block 0x804f915 and it returns, control flow will return to one of the basic blocks following the call site of the shown function and NOT a call site of _IO_vfprintf_5. This is modelled with a compensating edge (darkblue below) that connects the return block of _IO_vfprintf_5 with the return block of the depicted function.

Conference WCRE05; Pittsburgh Pennsylvania

Conference DRM05; Alexandria VA USA