Table of contents

3.1 Plug-ins modified. 1

3.2 Address abstraction – IAddress interface. 2

3.3 Address factory. 2

3.4 Binary parser enhancements. 3

3.5 Address factory usage. 3

4 Advantages. 3

1 CDT 2.0 problems

CDT 2.0 has several problems that prevent it from usage for 64-bit platform. They are as follows.

l Problems with addresses

– CDT uses Java long type to manipulate with pointers

– CDT assumes that addresses may be ONLY 32bit

– All address operations are done as regular Java long operations (+,-,<,>,==)

l C/C++ “long” type is handled correctly

– CDT assumes that “long” is 32bit length however it is 64 bit length on Linux 64bit platforms and 32 bit length on Windows 64bit platform

l ELF64 binary format which is used on Linux 64bit platforms is not supported

– As the result information about following binary files is not displayed correctly in C/C++ perspective

l Object files - *.o files

l Shared libraries - *.so files

l Binary archives - *.a

l Binary executables

2 Design solution

Design solution was concentrated on minimizing modifications to the CDT concept and on providing extensible solution. Each problem was addressed respectively.

l Introduce new type to handle pointers in CDT

– Introduce new interface which supports all operations necessary for pointers

– Replace all use cases where address is interpreted as Java long are with new interface

– Introduce address factory to enable creation of particular address object

l Enhance ELF binary parser to support ELF64 binary format

l Correct interpretation of “long” C/C++ variables

3 High Level Design

3.1 Plug-ins modified

Following plug-ins should be modified during CDT enhancement

– org.eclipse.cdt.core

– org.eclipse.cdt.debug.core

– org.eclipse.cdt.debug.mi.core

– org.eclipse.cdt.debug.ui

– org.eclipse.cdt.debug.mi.ui

3.2 Address abstraction – IAddress interface

Key point of 64bit support is new interface called IAddress.

l Represents C/C++ address in CDT

l Has all methods necessary to manipulate address

– Comparison

– Add/Subtraction

– Conversion to string

Address interface is defined as follows

public interface IAddress

{

IAddress add(BigInteger offset);

BigInteger getMaxOffset();

BigInteger distance(IAddress other);

int compareTo(IAddress addr);

boolean equals(IAddress addr);

boolean isZero();

boolean isMax();

String toString(int radix);

String toString();

String toHexAddressString();

int getDigitsNum();

int getCharsNum();

}

l Two new classes are defined to implement new interface – Addr32 and Addr64. These classes provide concrete behavior of addresses depending on target system

l All places in CDT where addresses were interpreted as Java long type were replaced with IAddress abstraction

3.3 Address factory

Because address is represented as Java interface in CDT we need address factory to have ability to create address objects

Address factory is defined as an interface which supports address creation

public interface IAddressFactory

{

IAddress getZero();

IAddress getMax();

IAddress createAddress(String addr);

IAddress createAddress(String addr, int radix);

}

Two new classes are defined to implement address factories – Addr32Factory and Addr64Factory. These classes provide concrete behavior of addresses factories depending on target system

3.4 Binary parser enhancements

Modification to binary parser consists of two changes

ELF64 format support

ELF64 is quite common to ELF format so the decision was to modify ELF parser rather than to create new ELF64 parser so modifications to CDT are minimal
Only differences between ELF64 and ELF formats are 64-bit addresses and 64-bit offsets

i. Java long is steel used as offset in ELF64 file because all Java I/O method operates with long as file offset. Offset is only used to read information from ELF64 file, so it is impossible to have offsets greater than Long.MAX_VALUE

New method to support address factory

Existing IBinaryParser.IBinaryObject interface is enhanced to have getAddressFactory() method
This interface provides to the CDT framework all information about binary file which is going to be debugged so it is most appropriate place to define nature of address
IBinaryParser interface is implemented by various binary parsers provided with CDT (ELF,COFF,XCOFF,PE). All other binary parsers except ELF were modified to simply provide Addr32Factory in getAddressFactory() method so 32-bit addresses are used.

3.5 Address factory usage

Access to address factory is required on different levels of CDT model. Several elements of CDT model were enhanced to have references to IAddressFactory to provide ability to create address objects on different levels of CDT model. They are

l IBinary – represents binary file in C model

l CDebugTarget – represents C debug target. It is used to communicate to upper Eclipse debug framework org.eclipse.debug.core and to provide information to debug UI level

l Target – represents debug target in terms of CDI (Common Debug Interface) model on MI level.

As the result

l CDT operates address abstractions which encapsulate particular addresses behavior

l Polymorphism of addresses is provided using address factories

l Concrete address factory is created based on format of executable

4 Advantages

l Modifications to CDT are minimal

– All places where address is used as Java long were replaced with IAddress

l CDT does not depend on address nature

– In future we may invent 16bit address for embedded systems for example

– In this case we will need to provide proper binary parser and debugger. There won’t be need to modify CDT.

l IAddress fully encapsulates address behavior

– Places where addresses are manipulated are clear to understand and maintain

– No need to have utilities to convert Java long to address string

l The same version of CDT code is able to work with 32bit and 64bit applications (And any other address size in the future)

– It is possible to have two debug sessions now with different targets. For example

– One local session for 32bit application

– And remote for 64 bit application