Deos MLD Antero Base Camp Project
Enable the DDC-I Mixed-Language Debugger to interact with a Deos target.
Description
The DDC-I Mixed-Language Debugger (MLD) needs to be extended to support debugging Deos targets. This capability need go no farther than supporting existing Insight Debugger capabilities. More advanced features, such as thread awareness and debugging multi-processes from a single MLD window can be deferred to a later release.
Status
Antero Base
| Antero Milestones | Due Date | Estimated Delivery | Delivered | Percentage Complete |
|---|---|---|---|---|
| [1] DDC-I MLD Debugger support for Deos Targets | 15-Mar-09 | 23-Feb-09 | 23-Feb-09 | 100% |
| [2] DDC-I MLD Debugger connect to Deos target | 15-Mar-09 | 23-Feb-09 | 23-Feb-09 | 100% |
| [3] PPC support Release | 15-Mar-09 | 23-Feb-09 | 23-Feb-09 | 100% |
| [4] X86 support Release | 15-Mar-09 | 23-Feb-09 | 23-Feb-09 | 100% |
Antero Base 1
| Antero Base 1 - Milestones | Due Date | Estimated Delivery | Delivered | Percentage Complete |
|---|---|---|---|---|
| [5] DDC-I MLD Debugger support for Deos Shared library Debugging | TBD | TBD | TBD | 8% |
| [6] Testing (this is very open ended) | TBD | TBD | TBD | 0% |
[1] DDC-I MLD Debugger support for Deos Targets
| Task | Dependency | Assignee | Original Estimate | Elapsed | Remaining |
|---|---|---|---|---|---|
| 1.0 Need to add capability of opening debug sections of a file by finding the debug link information end going to that file | TBD | karl | 32 | 8 | 0 |
| Totals | 32 | 8 | 0 | ||
[2] DDC-I MLD Debugger connect to Deos target
tardebug needs to be modified to give appropriate parameters to GUI so it can invoke MLD properly. tardebug will start a target gdbserver for the application to be debugged and let the GUI know what ethernet address and port the MLD should use to communicate with the gdbserver. The GUI will invoke the MLD with the proper communication options. (Note: MLD will be invoked with the -noload option since the application will already be loaded by the OS). This tool needs to be able to provide the MLD communications options to communicate with the application in a form that scripts can use to invoke the MLD when doing automated testing. There are several options here.
- The GUI invokes TAR_Debug including passing the MLD command line options. Tardebug does much of what it does now and then invokes the MLD with the proper command line options and the communications options appended to the MLD invocation.
- The MLD gets some additional command line option that lets it know to invoke a version of tardebug that will start gdbserver and let the debugger know how to open a connection with gdbserver.
- When starting a debug session for Deos, the GUI runs a version of Tardebug that starts gdbserver and returns the communication parameters for communication with the gdbserver. The GUI then invokes the MLD with the proper communication options.
| Task | Dependency | Assignee | Original Estimate | Elapsed | Remaining |
|---|---|---|---|---|---|
| 2.0 GUI or MLD changes | TBD | TBD | 24 | 22 | 0 |
| 2.1 tardebug changes | TBD | Ryan | 16 | 4 | 0 |
| Totals | 40 | 26 | 0 | ||
[3] PPC support
| Task | Dependency | Assignee | Original Estimate | Elapsed | Remaining |
|---|---|---|---|---|---|
| 3.0 MLD for PPC already supports the GDB protocol, so much of the implementation is in place. | TBD | karl | 1 | 8 | 0 |
| 3.1 Need to account for any differences in the protocol messages. | TBD | karl | 16 | 1 | 0 |
| 3.2 Need to account for any special startup needs (including symbols that are used by the debugger) | TBD | karl | 24 | 1 | 0 |
| 3.3 Will need to be able to detect that we are to use gdb protocol, but are not talking to the simulator and are not talking to the Abatron JTAG. | TBD | karl | 16 | 1 | 0 |
| Totals | 57 | 11 | 0 | ||
[4] X86 support
| Task | Dependency | Assignee | Original Estimate | Elapsed | Remaining |
|---|---|---|---|---|---|
| 4.0 MLD for 80x86 does not support the GDB protocol, but much of the low level code from the PPC or C4X implementations can be modified to support the protocol. | TBD | karl | 32 | 17 | 0 |
| 4.1 Need to account for any differences in the protocol messages. | TBD | karl | 16 | 17 | 0 |
| 4.2 Command line options and paths to establishing the target connection using GDB need to be put into place. Currently ethernet options for 80x86 targets are for talking to an ethernet debug monitor so would need to be handled somewhat differently. | TBD | karl | 16 | 17 | 0 |
| 4.3 All of the routines in src\target_interface_process\target_dependent\Cross_80x86\dbm_b.80x86.ada need to be modified to detect GDB connection and use GDB interface. | TBD | karl | 60 | 17 | 0 |
| 4.4 Need to account for any special startup needs (including symbols that are used by the debugger) | TBD | karl | 32 | 17 | 0 |
| Totals | 156 | 85 | 0 | ||
[5] DDC-I MLD Debugger support for Deos Shared library Debugging
There needs be changes to allow the handling of debug information about code in shared libraries. This is probably the most challenging part, and may be something to classify as "nice to have" for the initial release.
| Task | Dependency | Assignee | Original Estimate | Elapsed | Remaining |
|---|---|---|---|---|---|
| 5.0 This involves handling extended gdb protocol messages to tell us that a shared library has been loaded and where to get its debug information. The debugger needs to be sure to handle offsets given in the debug information as offsets into the debug information in the proper file | TBD | Karl | 60 | 4 | 56 |
| 5.1 Code in shared libraries is relocated when an application uses it, and the DWARF information for the shared library can not account for that. Therefore, addresses in DWARF will need to be adjusted to access variables properly. As noted above, the DWARF handling does this for one relocation (for example the RTX case), but this involves keeping track of multiple different adjustments to be made. | TBD | Karl | 80 | 4 | 76 |
| 5.2 If the MLD has been notified that a shared library has been loaded or unloaded, then the next time it stops(or at least if it needs debug information), it needs to query for the list of loaded shared libraries and adjust for this by (if necessary) reading in new debug information and adjusting relocations. This also needs to take place at startup, at least if not stopped at the "start" location. | TBD | Karl | 60 | 8 | 52 |
| 5.3 Shared libraries can be loaded, unloaded, and loaded again with its relocation being different from the original load location. The MLD handling of relocations needs to be sure to handle that. (I think this is a subset of 5.2.) | TBD | Karl | 1 | 1 | 0 |
| Totals | 201 | 17 | 184 | ||
[6] Testing (this is very open ended)
| Task | Dependency | Assignee | Original Estimate | Elapsed | Remaining |
|---|---|---|---|---|---|
| 6.0 Setting up an automated test capability that can run the current MLD test suite without need for manual intervention. | TBD | karl | 60 | 0 | 60 |
| 6.1 Modifying/adding new tests (open ended). | TBD | karl | 120 | 0 | 120 |
| Totals | 180 | 0 | 180 | ||
Risks
Insight Host client and Deos GDB server PCRs need to be assessed. The outcome may affect the task list above.
Deos Current GDB Interface
Standard GDB Interface
The current Deos GDB server interface is compatible with the Insight 6.5 debugger with minor mods to support shared library debugging. Here is the interface:
| Command | Description |
|---|---|
| `!' | Enable extended mode. In extended mode, the remote server is made persistent. The `R' packet is used to restart the program being debugged.
Reply: `OK' The remote target both supports and has enabled extended mode. |
| `?' | Indicate the reason the target halted. The reply is the same as for step and continue. |
| `A arglen,argnum,arg,...' | Not supported (now that Deos supports argv perhaps it should be added) |
| `b baud' | Not supported |
| `B addr,mode' | Not supported |
| `bc' | Not supported |
| `bs' | Not supported |
| `c [addr]' | Continue. [addr] is not currently supported and is ignored
Reply: `S AA [DeosLibraryExtension]' The program received signal number AA (a two-digit hexadecimal number). For info on [DeosLibraryExtension] see Extension to the GDB interface |
| `C sig[;addr]' | Continue with signal sig (hex signal number). [;addr] is not currently supported and is ignored
Reply: see Continue. |
| `d' | ignored |
| `D' `D;pid' | quit debugging. ;pid is ignored. |
| `F RC,EE,CF;XX' | Not supported |
| `g' | Read general registers.
Reply: `XX...' Each byte of register data is described by two hex digits. The bytes with the register are transmitted in target byte order. ppc order/size: r0-r31 (32 bits each) fpr0-fpr31 (64 bits each) srr0 (pc), srr1 (msr), cr, lr, ctr, xer (32 bits each), fpscr (64 bits). x86 order/size: eax, ecx, edx, ebx, esp, ebp, esi, edi, eip, eflags, cs, ss, ds, es, fs, gs (32 bits each), st0-st7 (80 bits each) fctrl, fstat, ftag, fiseg, fioff, foseg, fooff, fop (32 bits each), xmm0-xmm7 (128 bits each), mxcsr (32 bits). `E NN' Not used. |
| `G XX...' | Write general registers. See read general registers packet, for a description of the XX... data.
Reply: `OK' for success `E NN' not Not used. |
| `H c thread-id' | Ignored
Reply: `OK' for success |
| `i [addr[,nnn]]' | Not supported |
| `I' | Not supported |
| `k' | close gdb server |
| `m addr,length' | Read length bytes of memory starting at address addr. Note that addr may not be aligned to any particular boundary. The stub need not use any particular size or alignment when gathering data from memory for the response; even if addr is word-aligned and length is a multiple of the word size, the stub is free to use byte accesses, or not. For this reason, this packet may not be suitable for accessing memory-mapped I/O devices.
Reply: `XX...' Memory contents; each byte is transmitted as a two-digit hexadecimal number. The reply may contain fewer bytes than requested if the server was able to read only part of the region of memory. `E NN' Not used. |
| `M addr,length:XX...' | Write length bytes of memory starting at address addr. XX... is the data; each byte is transmitted as a two-digit hexadecimal number.
Reply: `OK' for success `E NN' for an error |
| `p n' | Not supported |
| `P n...=r...' | Not supported |
| `q name params...' | only the options documented in Extension to the GDB interface are supported. |
| `Q name params...' | Not supported. |
| `r' | Not supported. |
| `R' | Not supported. |
| `s [addr]' | Single step. [addr] is ignored.
Reply: see Continue. |
| `S sig[;addr]' | Step with signal. [;addr] is ignored.
Reply: see Continue. |
| `t addr:PP,MM' | Not supported. |
| `T thread-id' | thread-id is ignored.
Reply: `OK' for success `E NN' not used |
| `v*' | Not supported. |
| `X addr,length:XX..' | Not supported. |
| `z*' | Not supported. |
| `Z*' | Not supported. |
Items identified as 'Not supported' will return `'. Note: Just because an item is 'Not supported' does not mean it can't be supported it just was not needed when we first implemented the gdb server interface.
Extension to the GDB interface
Extensions to the reply messages
[DeosLibraryExtension] is an addition to continue/step reply packets:
`dll:dll;T' A change to the loaded libraries has been detected, GDB is expected to clear out the existing list of files then use qfDllInfo and qsDllInfo to retrieve the data on the loaded libraries.
Extensions to the q command
| Command | Description |
|---|---|
| `qfDllInfo' | Query for the first loaded library
Reply: `m Name=<file name> ,TextSeg=<hex text segment address>, DataSeg=<hex text segment address>' First loaded library data. `l' no libraries loaded or no new libraries since the last call. `E NN:<error message>' An error occurred. |
| `qsDllInfo' | Query the subsequent loaded library
Reply: `m Name=<file name> ,TextSeg=<hex text segment address>, DataSeg=<hex data segment address>' First loaded library data. `l' no more libraries loaded `E NN:<error message>' An error occurred. |
It looks like 'qXfer:libraries:read:annex:offset,length' has been added to gdb to do this. Changing to this would not be easy, it is also not clear when GDB calls 'qXfer:libraries:read'.
Symbols
In order to allow the smallest possible file to be loaded on the target and still enable debugging with symbols we strip the debug symbols in the exe/so and use objcopy with the --add-gnu-debuglink option to set the name of the file with the debug symbols in it. We do not currently specify a path (i.e. the file with symbols in it is expected to be in the directory as the local copy of the target file). Currently the debug symbols are the only thing in the file but this is not a requirement and we may change that in the future. Note: This is not really a 'Deos' extension but when I mentioned it while in PHX the last time I got some strange looks so I thought I would elaborate based on some quick research.
Legacy
The discovery of the --add-gnu-debuglink option is rather recent within our team and we do have some legacy exe/so's that do not use objcopy and the --add-gnu-debuglink option. Instead a file with the same name as the stripped exe/so with '-withwithsymbols' postpended to it is in the same directory as the local copy of the target file. It is not clear if GDB has to support this hack or not but it would probably be a good thing to support.
