[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

Acknowledgments

1. Introduction


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.1 Purpose

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


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.2 Document structure

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

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.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

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


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.1 Multi-arch

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

Each of these can be viewed as largely orthogonal:

multi

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


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

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.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

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.

path

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


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

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


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.1 Current Interface


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

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

source-for-thread-3

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:

Local Varible Window

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

var-with-struct-open

Memory Window

memory-for-thread-3

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

Registers Window

registers-for-thread-3

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


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.2 Navigation

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

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

thread-x-frame

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

xform


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.2.1 Display Navigation

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

Stack Window

stack-for-thread-3

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

threads-for-thread-3

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.

stack-buttons-3

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.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

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.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

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.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

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.

away


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.4.2 New Navigation Menus

Select Thread

insight-thread

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

is displayed.

Select Frame

insight-frame

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

is displayed.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

4. Insight internals


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

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.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

4.2 Changes

The following structural changes have been identified.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

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:


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

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:

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.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

5. Insight/GDB Interface


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

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.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

5.2 Changes

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


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

6. GDB internals


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

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.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

6.2 Changes

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

arch

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.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

7. GDB/Remote Target Inteface


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

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:

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

The protocol uses target architecture dependant mechanisms when transfering registers.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

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.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

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.


[Top] [Contents] [Index] [ ? ]

Table of Contents


[Top] [Contents] [Index] [ ? ]

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

[Top] [Contents] [Index] [ ? ]

About this document

This document was generated by Andrew Cagney on June, 11 2001 using texi2html

The buttons in the navigation panels have the following meaning:

Button Name Go to From 1.2.3 go to
[ < ] Back previous section in reading order 1.2.2
[ > ] Forward next section in reading order 1.2.4
[ << ] FastBack previous or up-and-previous section 1.1
[ Up ] Up up section 1.2
[ >> ] FastForward next or up-and-next section 1.3
[Top] Top cover (top) of document  
[Contents] Contents table of contents  
[Index] Index concept index  
[ ? ] About this page  

where the Example assumes that the current position is at Subsubsection One-Two-Three of a document of the following structure:

This document was generated by Andrew Cagney on June, 11 2001 using texi2html