text: Multi-arching Insight and GDB:
  This document discusses changes to GDB and Insight that will allow the debugging of unified memory, asymetric, multi-threaded targets.
  Between Insight and GDB, the following layers and interfaces can be identified:
  User Interface (Insight GUI)
  Insight - GDB interface
  GDB - target interface
  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)
  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:
  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
  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.
  The memory window displays the contents of the current threads address space.
  The register window displays the registers for the current thread's current frame.
  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:
  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.
  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.
  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.
  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.
  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
  The thread menu, present on display windows, allows the user to specify that:
  a specific thread
  The Select Frame menu, present on display windows, allows the user to specify that the selected threads:
  specific stack frame
  4. Insight internals
  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.
  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)
  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 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.
  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
  The current GDB architecture is based around a single global state. That global state includes:
  abstracts the target ABI's stack frame
  struct gdbarch
  the architecture of the target
  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.
  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:
  value of selected registers
  Both GDB and the remote target assume the architecture of the current target.
  The protocol uses target architecture dependant mechanisms when transfering registers.
  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.
  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.