Acknowledgments

1. Introduction

1.1 Purpose

This document discusses changes to GDB and Insight that will allow the debugging of unified memory, asymetric, multi-threaded targets.

1.2 Document structure

Between Insight and GDB, the following layers and interfaces can be identified:

• User Interface (Insight GUI)
• Insight
• Insight - GDB interface
• GDB
• GDB - target interface
• Target

The next chapter provides a brief review of multi-arch and what it means in the current context.

Follow that, succeeding chapters address each of the above layers and interfaces discussing the intended changes. At each stage, the emphasis of the document is on the interfaces rather than the details of the internal changes.

This document refers to multi-threaded targets. Such a target has multiple execution units. Those execution units could equally be pthreads or processors.

2. Single-memory, asymetric, multi-threaded GDB

2.1 Multi-arch

The original GDB release included a number of architectural restrictions. In particular, GDB was was only capable of debugging:

• single thread (or processor)
• single instruction set architecture (symetric)
• single address space

Each of these can be viewed as largely orthogonal:

The elimination of these restrictions is a long term objective of GDB.

2.2 Current overall state of GDB

As GDB has evolved, some of these restrictions have been partially addressed. In particular:

multi-thread

GDB includes support for multi-threaded targets. Unfortunatly, that support does not allow GDB or Insight to debug more than one thread simultaneously - there is always a single current thread and the user must explicitly switch between them.

multi-arch - single architecture variant

GDB includes support for debugging variants of an instruction set architecture. Unfortunatly, that support does not allow GDB or Insight to debug different architecture variants simultaneously - all threads must have an identical architecture.

2.3 Single-memory, asymetric, multi-threaded GDB?

The objective of this document is to address the restrictions that limit GDB's ability to debug multi-threaded targets where each thread can have a different instruction set architecture.

The restriction that GDB can not debug targets with multiple address spaces has not being addressed.

3. User/Insight Interface (the GUI and GDB CLI).

3.1 Current Interface

3.1.1 Display

The current Insight interface provides a number of mechanisms for examining the target's state. At any time, each of these mechanisms is providing a differeing view of a single thread (current thread) and one of its frame (current frame).

Source and Control Window

The Source and Control window displays the source source (and assembler) for the current threads, current frame.

In addition, the Source and Control window provide:

• mechanisms for controlling a program's execution.
• a source code browser (in conjunction with the Function Browser Window)

Local Varible Window

The local variable window provides a way of examing the local variables found on the current thread's stack frame.

Memory Window

The memory window displays the contents of the current threads address space.

Registers Window

The register window displays the registers for the current thread's current frame.

3.2 Navigation

Insight provides two mechanisms for changing the current target state being displayed by the Display Windows:

• select thread
• select frame

That navigation provides a mechanism for navigating allows the user to move within a two dimentional space:

At all times, there is only a single current thread and stack frame. Selecting a new thread or frame will update all display windows:

3.2.1 Display Navigation

Insight provides the following mechanisms for changing the current thread and that threads stack frame.

Stack Window

The stack window provides a browserable list of the current threads stack frames. This can be used to change the current frame for the current thread.

Thread/Process Window

The thread/process window provides a browserable list of the targets threads. This can be used to change the current thread (and hence the current stack).

Stack Frame Buttons

Found on the source/control window, these buttons provide a mechanism for moving between the current threads stack frames.

Console Window

The console window provides direct access to GDB's command line interpreter. The console window can be used to directly display and modify the target state.

3.3 Other Windows

The following are also available.

Function Browser Window

The Function Browser Window allows the user to browse various source files. It does not affect the current thread or current stack frame.

3.4 Changes

The most significnat restriction in the existing Insight GUI interface its its inability to display more than one thread simultaneously. As noted above, at any time Insight only displays the current thread/frame.

3.4.1 Navigating Way

To address the restriction of only a current thread/frame, it is proposed that Insight be modified so that all Display Windows include mechanims for selecting the thread/frame being displayed.

When either the thread or frame is explicitly set, the window is described as being navigated away from current. Once a Display Window has been navigated away from the current thread/frame, it is no longer affected by changes initiated by the Navigation Mechanims such as the Stack Window and Thread Window.

3.4.2 New Navigation Menus

Select Thread

The thread menu, present on display windows, allows the user to specify that:

• the current thread
• a specific thread

is displayed.

Select Frame

The Select Frame menu, present on display windows, allows the user to specify that the selected threads:

• current stack frame
• specific stack frame

is displayed.

4. Insight internals

4.1 Current State

The current Insight implementation, reflecting GDB's internals, is very single architecture, single thread, single frame centric. All display windows rely on global state and assume that that global state will rarely, if ever, change.

4.2 Changes

The following structural changes have been identified.

4.2.1 Display Window have local state

Each display window needs to modified that it uses local state to determine what to display. In particular, each window will need to know its:

• thread (or current thread)
• frame (or current frame)
• architecture (or current architecture)

4.2.2 Events

So that Display Windows tracking the current thread, frame and architecture are kept synchronized, the event mechanism used by Insight will need to be extended to include the notifications:

• change the current frame
• change the current thread
• change the current architecture

When a user changes the current thread, frame or architecture, the change event would be broadcast so that all interested display windows would update accordingly.

5. Insight/GDB Interface

5.1 Current Interface

The existing GDB / Insight interface assumes that there is only a single current architecture, thread and frame. Moving between architectures, threads and frames is an expensive (threads), if not impossible (architecture) operation.

5.2 Changes

Reflecting the changes to both the GUI and Insights internals, the GDB/Insight interface will need to be extended to support:

• a mechanism for identifying individual frames (and their corresponding thread and architecture).
• a mechanism for tracking what GDB's CLI considers current (frame, thread and architecture). This would include an event mechanism for notifying Insight of any changes to the current frame, thread or architecture.

6. GDB internals

6.1 Current State

The current GDB architecture is based around a single global state. That global state includes:

struct frame

abstracts the target ABI's stack frame

struct gdbarch

the architecture of the target

struct thread_info

the debug and run state of a target thread

Because of the way the global state is managed (eg changing threads invalidates all frames) there are also certain implicit relationships between that global states components.

GDB uses this single global state to track the current thread. When ever a new thread is selected, the current state is discarded and a new state created. This behavour has serious consequences for GUI interfaces which expect to be both displaying multiple-thread states simultaneously and quickly and efficiently switching between threads.

6.2 Changes

The proposed change (discussed on GDB Discussion Mailing List) is to:

• add an explicit object relationship between the thread, frame and architecture
• replace the global state with an explict thread and frame parameters
• Extend BFD so that it knows about more than one architecture within a single object file. This is so that given a particular address, GDB will be able to disassemble instructions at that address correctly, i.e. invoking the appropriate disassembler function. GDB will be able to map an architecture to an address using information provided by BFD.

By giving each frame an explict architecture, GDB's restriction that there can only be a single global architecture is removed.

By making the thread-frame relationship explicit, there is no longer a need to discard all thread/frame information when switching threads.

By making the frame an explicit parameter, the need, by GUI's to constantly switch the current thread/frame is removed.

7. GDB/Remote Target Inteface

7.1 Current Interface

GDB interacts with a remote target using the "GDB remote protocol". This protocol includes mechansims that allow GDB to obtain the current state of the target including:

• stop reason
• current thread
• value of selected registers
• memory

Both GDB and the remote target assume the architecture of the current target.

The protocol uses target architecture dependant mechanisms when transfering registers.

7.2 Changes

The protocol needs to be extended so that the target can notify GDB of the archhitecture of the current thread.

The protocol may also need to be extended so that support a target independant representation of registers.

7.2.1 Protocol Changes

Below are draft changes to the remote protocol that address the above:

T00;...;Architecture=<arch>;...

The T packet is used to report the reason the target stopped to GDB. That packet includes information such as the processor and that processors registers. The packet can be extended to include the architecture of the processor that halted.

qArchitecture

An alternative to extending the T status packet, is to add an architecture query packet to the protocol.

T00;...;<regnum>!<register-value>;...

The current "GDB remote protocol" transfers registers using a target dependant byte ordering. Using a target independant format would allow GDB to process register values received from the target without knowing that targets architecture.

Table of Contents

1. Introduction

1.1 Purpose
1.2 Document structure

2. Single-memory, asymetric, multi-threaded GDB

2.1 Multi-arch
2.2 Current overall state of GDB
2.3 Single-memory, asymetric, multi-threaded GDB?

3. User/Insight Interface (the GUI and GDB CLI).

3.1 Current Interface

3.1.1 Display

3.2 Navigation

3.2.1 Display Navigation

3.3 Other Windows
3.4 Changes

3.4.1 Navigating Way
3.4.2 New Navigation Menus

4. Insight internals

4.1 Current State
4.2 Changes

4.2.1 Display Window have local state
4.2.2 Events

5. Insight/GDB Interface

5.1 Current Interface
5.2 Changes

6. GDB internals

6.1 Current State
6.2 Changes

7. GDB/Remote Target Inteface

7.1 Current Interface
7.2 Changes

7.2.1 Protocol Changes

Short Table of Contents

1. Introduction
2. Single-memory, asymetric, multi-threaded GDB
3. User/Insight Interface (the GUI and GDB CLI).
4. Insight internals
5. Insight/GDB Interface
6. GDB internals
7. GDB/Remote Target Inteface

About this document

• 1. Section One
• 1.1 Subsection One-One
• ...
• 1.2 Subsection One-Two
• 1.2.1 Subsubsection One-Two-One
• 1.2.2 Subsubsection One-Two-Two
• 1.2.3 Subsubsection One-Two-Three     <== Current Position
• 1.2.4 Subsubsection One-Two-Four
• 1.3 Subsection One-Three
• ...
• 1.4 Subsection One-Four