| This is gdb.info, produced by makeinfo version 4.13 from ./gdb.texinfo. |
| |
| INFO-DIR-SECTION Software development |
| START-INFO-DIR-ENTRY |
| * Gdb: (gdb). The GNU debugger. |
| * gdbserver: (gdb) Server. The GNU debugging server. |
| END-INFO-DIR-ENTRY |
| |
| Copyright (C) 1988-2013 Free Software Foundation, Inc. |
| |
| Permission is granted to copy, distribute and/or modify this document |
| under the terms of the GNU Free Documentation License, Version 1.3 or |
| any later version published by the Free Software Foundation; with the |
| Invariant Sections being "Free Software" and "Free Software Needs Free |
| Documentation", with the Front-Cover Texts being "A GNU Manual," and |
| with the Back-Cover Texts as in (a) below. |
| |
| (a) The FSF's Back-Cover Text is: "You are free to copy and modify |
| this GNU Manual. Buying copies from GNU Press supports the FSF in |
| developing GNU and promoting software freedom." |
| |
| This file documents the GNU debugger GDB. |
| |
| This is the Tenth Edition, of `Debugging with GDB: the GNU |
| Source-Level Debugger' for GDB (GDB) Version 7.6.50.20131211-cvs. |
| |
| Copyright (C) 1988-2013 Free Software Foundation, Inc. |
| |
| Permission is granted to copy, distribute and/or modify this document |
| under the terms of the GNU Free Documentation License, Version 1.3 or |
| any later version published by the Free Software Foundation; with the |
| Invariant Sections being "Free Software" and "Free Software Needs Free |
| Documentation", with the Front-Cover Texts being "A GNU Manual," and |
| with the Back-Cover Texts as in (a) below. |
| |
| (a) The FSF's Back-Cover Text is: "You are free to copy and modify |
| this GNU Manual. Buying copies from GNU Press supports the FSF in |
| developing GNU and promoting software freedom." |
| |
| |
| File: gdb.info, Node: Writing a Frame Filter, Next: Inferiors In Python, Prev: Frame Decorator API, Up: Python API |
| |
| 23.2.2.11 Writing a Frame Filter |
| ................................ |
| |
| There are three basic elements that a frame filter must implement: it |
| must correctly implement the documented interface (*note Frame Filter |
| API::), it must register itself with GDB, and finally, it must decide |
| if it is to work on the data provided by GDB. In all cases, whether it |
| works on the iterator or not, each frame filter must return an |
| iterator. A bare-bones frame filter follows the pattern in the |
| following example. |
| |
| import gdb |
| |
| class FrameFilter(): |
| |
| def __init__(self): |
| # Frame filter attribute creation. |
| # |
| # 'name' is the name of the filter that GDB will display. |
| # |
| # 'priority' is the priority of the filter relative to other |
| # filters. |
| # |
| # 'enabled' is a boolean that indicates whether this filter is |
| # enabled and should be executed. |
| |
| self.name = "Foo" |
| self.priority = 100 |
| self.enabled = True |
| |
| # Register this frame filter with the global frame_filters |
| # dictionary. |
| gdb.frame_filters[self.name] = self |
| |
| def filter(self, frame_iter): |
| # Just return the iterator. |
| return frame_iter |
| |
| The frame filter in the example above implements the three |
| requirements for all frame filters. It implements the API, self |
| registers, and makes a decision on the iterator (in this case, it just |
| returns the iterator untouched). |
| |
| The first step is attribute creation and assignment, and as shown in |
| the comments the filter assigns the following attributes: `name', |
| `priority' and whether the filter should be enabled with the `enabled' |
| attribute. |
| |
| The second step is registering the frame filter with the dictionary |
| or dictionaries that the frame filter has interest in. As shown in the |
| comments, this filter just registers itself with the global dictionary |
| `gdb.frame_filters'. As noted earlier, `gdb.frame_filters' is a |
| dictionary that is initialized in the `gdb' module when GDB starts. |
| What dictionary a filter registers with is an important consideration. |
| Generally, if a filter is specific to a set of code, it should be |
| registered either in the `objfile' or `progspace' dictionaries as they |
| are specific to the program currently loaded in GDB. The global |
| dictionary is always present in GDB and is never unloaded. Any filters |
| registered with the global dictionary will exist until GDB exits. To |
| avoid filters that may conflict, it is generally better to register |
| frame filters against the dictionaries that more closely align with the |
| usage of the filter currently in question. *Note Python |
| Auto-loading::, for further information on auto-loading Python scripts. |
| |
| GDB takes a hands-off approach to frame filter registration, |
| therefore it is the frame filter's responsibility to ensure |
| registration has occurred, and that any exceptions are handled |
| appropriately. In particular, you may wish to handle exceptions |
| relating to Python dictionary key uniqueness. It is mandatory that the |
| dictionary key is the same as frame filter's `name' attribute. When a |
| user manages frame filters (*note Frame Filter Management::), the names |
| GDB will display are those contained in the `name' attribute. |
| |
| The final step of this example is the implementation of the `filter' |
| method. As shown in the example comments, we define the `filter' |
| method and note that the method must take an iterator, and also must |
| return an iterator. In this bare-bones example, the frame filter is |
| not very useful as it just returns the iterator untouched. However |
| this is a valid operation for frame filters that have the `enabled' |
| attribute set, but decide not to operate on any frames. |
| |
| In the next example, the frame filter operates on all frames and |
| utilizes a frame decorator to perform some work on the frames. *Note |
| Frame Decorator API::, for further information on the frame decorator |
| interface. |
| |
| This example works on inlined frames. It highlights frames which are |
| inlined by tagging them with an "[inlined]" tag. By applying a frame |
| decorator to all frames with the Python `itertools imap' method, the |
| example defers actions to the frame decorator. Frame decorators are |
| only processed when GDB prints the backtrace. |
| |
| This introduces a new decision making topic: whether to perform |
| decision making operations at the filtering step, or at the printing |
| step. In this example's approach, it does not perform any filtering |
| decisions at the filtering step beyond mapping a frame decorator to |
| each frame. This allows the actual decision making to be performed |
| when each frame is printed. This is an important consideration, and |
| well worth reflecting upon when designing a frame filter. An issue |
| that frame filters should avoid is unwinding the stack if possible. |
| Some stacks can run very deep, into the tens of thousands in some |
| cases. To search every frame to determine if it is inlined ahead of |
| time may be too expensive at the filtering step. The frame filter |
| cannot know how many frames it has to iterate over, and it would have |
| to iterate through them all. This ends up duplicating effort as GDB |
| performs this iteration when it prints the frames. |
| |
| In this example decision making can be deferred to the printing step. |
| As each frame is printed, the frame decorator can examine each frame in |
| turn when GDB iterates. From a performance viewpoint, this is the most |
| appropriate decision to make as it avoids duplicating the effort that |
| the printing step would undertake anyway. Also, if there are many |
| frame filters unwinding the stack during filtering, it can |
| substantially delay the printing of the backtrace which will result in |
| large memory usage, and a poor user experience. |
| |
| class InlineFilter(): |
| |
| def __init__(self): |
| self.name = "InlinedFrameFilter" |
| self.priority = 100 |
| self.enabled = True |
| gdb.frame_filters[self.name] = self |
| |
| def filter(self, frame_iter): |
| frame_iter = itertools.imap(InlinedFrameDecorator, |
| frame_iter) |
| return frame_iter |
| |
| This frame filter is somewhat similar to the earlier example, except |
| that the `filter' method applies a frame decorator object called |
| `InlinedFrameDecorator' to each element in the iterator. The `imap' |
| Python method is light-weight. It does not proactively iterate over |
| the iterator, but rather creates a new iterator which wraps the |
| existing one. |
| |
| Below is the frame decorator for this example. |
| |
| class InlinedFrameDecorator(FrameDecorator): |
| |
| def __init__(self, fobj): |
| super(InlinedFrameDecorator, self).__init__(fobj) |
| |
| def function(self): |
| frame = fobj.inferior_frame() |
| name = str(frame.name()) |
| |
| if frame.type() == gdb.INLINE_FRAME: |
| name = name + " [inlined]" |
| |
| return name |
| |
| This frame decorator only defines and overrides the `function' |
| method. It lets the supplied `FrameDecorator', which is shipped with |
| GDB, perform the other work associated with printing this frame. |
| |
| The combination of these two objects create this output from a |
| backtrace: |
| |
| #0 0x004004e0 in bar () at inline.c:11 |
| #1 0x00400566 in max [inlined] (b=6, a=12) at inline.c:21 |
| #2 0x00400566 in main () at inline.c:31 |
| |
| So in the case of this example, a frame decorator is applied to all |
| frames, regardless of whether they may be inlined or not. As GDB |
| iterates over the iterator produced by the frame filters, GDB executes |
| each frame decorator which then makes a decision on what to print in |
| the `function' callback. Using a strategy like this is a way to defer |
| decisions on the frame content to printing time. |
| |
| Eliding Frames |
| -------------- |
| |
| It might be that the above example is not desirable for representing |
| inlined frames, and a hierarchical approach may be preferred. If we |
| want to hierarchically represent frames, the `elided' frame decorator |
| interface might be preferable. |
| |
| This example approaches the issue with the `elided' method. This |
| example is quite long, but very simplistic. It is out-of-scope for |
| this section to write a complete example that comprehensively covers |
| all approaches of finding and printing inlined frames. However, this |
| example illustrates the approach an author might use. |
| |
| This example comprises of three sections. |
| |
| class InlineFrameFilter(): |
| |
| def __init__(self): |
| self.name = "InlinedFrameFilter" |
| self.priority = 100 |
| self.enabled = True |
| gdb.frame_filters[self.name] = self |
| |
| def filter(self, frame_iter): |
| return ElidingInlineIterator(frame_iter) |
| |
| This frame filter is very similar to the other examples. The only |
| difference is this frame filter is wrapping the iterator provided to it |
| (`frame_iter') with a custom iterator called `ElidingInlineIterator'. |
| This again defers actions to when GDB prints the backtrace, as the |
| iterator is not traversed until printing. |
| |
| The iterator for this example is as follows. It is in this section |
| of the example where decisions are made on the content of the backtrace. |
| |
| class ElidingInlineIterator: |
| def __init__(self, ii): |
| self.input_iterator = ii |
| |
| def __iter__(self): |
| return self |
| |
| def next(self): |
| frame = next(self.input_iterator) |
| |
| if frame.inferior_frame().type() != gdb.INLINE_FRAME: |
| return frame |
| |
| try: |
| eliding_frame = next(self.input_iterator) |
| except StopIteration: |
| return frame |
| return ElidingFrameDecorator(eliding_frame, [frame]) |
| |
| This iterator implements the Python iterator protocol. When the |
| `next' function is called (when GDB prints each frame), the iterator |
| checks if this frame decorator, `frame', is wrapping an inlined frame. |
| If it is not, it returns the existing frame decorator untouched. If it |
| is wrapping an inlined frame, it assumes that the inlined frame was |
| contained within the next oldest frame, `eliding_frame', which it |
| fetches. It then creates and returns a frame decorator, |
| `ElidingFrameDecorator', which contains both the elided frame, and the |
| eliding frame. |
| |
| class ElidingInlineDecorator(FrameDecorator): |
| |
| def __init__(self, frame, elided_frames): |
| super(ElidingInlineDecorator, self).__init__(frame) |
| self.frame = frame |
| self.elided_frames = elided_frames |
| |
| def elided(self): |
| return iter(self.elided_frames) |
| |
| This frame decorator overrides one function and returns the inlined |
| frame in the `elided' method. As before it lets `FrameDecorator' do |
| the rest of the work involved in printing this frame. This produces |
| the following output. |
| |
| #0 0x004004e0 in bar () at inline.c:11 |
| #2 0x00400529 in main () at inline.c:25 |
| #1 0x00400529 in max (b=6, a=12) at inline.c:15 |
| |
| In that output, `max' which has been inlined into `main' is printed |
| hierarchically. Another approach would be to combine the `function' |
| method, and the `elided' method to both print a marker in the inlined |
| frame, and also show the hierarchical relationship. |
| |
| |
| File: gdb.info, Node: Inferiors In Python, Next: Events In Python, Prev: Writing a Frame Filter, Up: Python API |
| |
| 23.2.2.12 Inferiors In Python |
| ............................. |
| |
| Programs which are being run under GDB are called inferiors (*note |
| Inferiors and Programs::). Python scripts can access information about |
| and manipulate inferiors controlled by GDB via objects of the |
| `gdb.Inferior' class. |
| |
| The following inferior-related functions are available in the `gdb' |
| module: |
| |
| -- Function: gdb.inferiors () |
| Return a tuple containing all inferior objects. |
| |
| -- Function: gdb.selected_inferior () |
| Return an object representing the current inferior. |
| |
| A `gdb.Inferior' object has the following attributes: |
| |
| -- Variable: Inferior.num |
| ID of inferior, as assigned by GDB. |
| |
| -- Variable: Inferior.pid |
| Process ID of the inferior, as assigned by the underlying operating |
| system. |
| |
| -- Variable: Inferior.was_attached |
| Boolean signaling whether the inferior was created using `attach', |
| or started by GDB itself. |
| |
| A `gdb.Inferior' object has the following methods: |
| |
| -- Function: Inferior.is_valid () |
| Returns `True' if the `gdb.Inferior' object is valid, `False' if |
| not. A `gdb.Inferior' object will become invalid if the inferior |
| no longer exists within GDB. All other `gdb.Inferior' methods |
| will throw an exception if it is invalid at the time the method is |
| called. |
| |
| -- Function: Inferior.threads () |
| This method returns a tuple holding all the threads which are valid |
| when it is called. If there are no valid threads, the method will |
| return an empty tuple. |
| |
| -- Function: Inferior.read_memory (address, length) |
| Read LENGTH bytes of memory from the inferior, starting at |
| ADDRESS. Returns a buffer object, which behaves much like an array |
| or a string. It can be modified and given to the |
| `Inferior.write_memory' function. In `Python' 3, the return value |
| is a `memoryview' object. |
| |
| -- Function: Inferior.write_memory (address, buffer [, length]) |
| Write the contents of BUFFER to the inferior, starting at ADDRESS. |
| The BUFFER parameter must be a Python object which supports the |
| buffer protocol, i.e., a string, an array or the object returned |
| from `Inferior.read_memory'. If given, LENGTH determines the |
| number of bytes from BUFFER to be written. |
| |
| -- Function: Inferior.search_memory (address, length, pattern) |
| Search a region of the inferior memory starting at ADDRESS with |
| the given LENGTH using the search pattern supplied in PATTERN. |
| The PATTERN parameter must be a Python object which supports the |
| buffer protocol, i.e., a string, an array or the object returned |
| from `gdb.read_memory'. Returns a Python `Long' containing the |
| address where the pattern was found, or `None' if the pattern |
| could not be found. |
| |
| |
| File: gdb.info, Node: Events In Python, Next: Threads In Python, Prev: Inferiors In Python, Up: Python API |
| |
| 23.2.2.13 Events In Python |
| .......................... |
| |
| GDB provides a general event facility so that Python code can be |
| notified of various state changes, particularly changes that occur in |
| the inferior. |
| |
| An "event" is just an object that describes some state change. The |
| type of the object and its attributes will vary depending on the details |
| of the change. All the existing events are described below. |
| |
| In order to be notified of an event, you must register an event |
| handler with an "event registry". An event registry is an object in the |
| `gdb.events' module which dispatches particular events. A registry |
| provides methods to register and unregister event handlers: |
| |
| -- Function: EventRegistry.connect (object) |
| Add the given callable OBJECT to the registry. This object will be |
| called when an event corresponding to this registry occurs. |
| |
| -- Function: EventRegistry.disconnect (object) |
| Remove the given OBJECT from the registry. Once removed, the |
| object will no longer receive notifications of events. |
| |
| Here is an example: |
| |
| def exit_handler (event): |
| print "event type: exit" |
| print "exit code: %d" % (event.exit_code) |
| |
| gdb.events.exited.connect (exit_handler) |
| |
| In the above example we connect our handler `exit_handler' to the |
| registry `events.exited'. Once connected, `exit_handler' gets called |
| when the inferior exits. The argument "event" in this example is of |
| type `gdb.ExitedEvent'. As you can see in the example the |
| `ExitedEvent' object has an attribute which indicates the exit code of |
| the inferior. |
| |
| The following is a listing of the event registries that are |
| available and details of the events they emit: |
| |
| `events.cont' |
| Emits `gdb.ThreadEvent'. |
| |
| Some events can be thread specific when GDB is running in non-stop |
| mode. When represented in Python, these events all extend |
| `gdb.ThreadEvent'. Note, this event is not emitted directly; |
| instead, events which are emitted by this or other modules might |
| extend this event. Examples of these events are |
| `gdb.BreakpointEvent' and `gdb.ContinueEvent'. |
| |
| -- Variable: ThreadEvent.inferior_thread |
| In non-stop mode this attribute will be set to the specific |
| thread which was involved in the emitted event. Otherwise, it |
| will be set to `None'. |
| |
| Emits `gdb.ContinueEvent' which extends `gdb.ThreadEvent'. |
| |
| This event indicates that the inferior has been continued after a |
| stop. For inherited attribute refer to `gdb.ThreadEvent' above. |
| |
| `events.exited' |
| Emits `events.ExitedEvent' which indicates that the inferior has |
| exited. `events.ExitedEvent' has two attributes: |
| |
| -- Variable: ExitedEvent.exit_code |
| An integer representing the exit code, if available, which |
| the inferior has returned. (The exit code could be |
| unavailable if, for example, GDB detaches from the inferior.) |
| If the exit code is unavailable, the attribute does not exist. |
| |
| -- Variable: ExitedEvent inferior |
| A reference to the inferior which triggered the `exited' |
| event. |
| |
| `events.stop' |
| Emits `gdb.StopEvent' which extends `gdb.ThreadEvent'. |
| |
| Indicates that the inferior has stopped. All events emitted by |
| this registry extend StopEvent. As a child of `gdb.ThreadEvent', |
| `gdb.StopEvent' will indicate the stopped thread when GDB is |
| running in non-stop mode. Refer to `gdb.ThreadEvent' above for |
| more details. |
| |
| Emits `gdb.SignalEvent' which extends `gdb.StopEvent'. |
| |
| This event indicates that the inferior or one of its threads has |
| received as signal. `gdb.SignalEvent' has the following |
| attributes: |
| |
| -- Variable: SignalEvent.stop_signal |
| A string representing the signal received by the inferior. A |
| list of possible signal values can be obtained by running the |
| command `info signals' in the GDB command prompt. |
| |
| Also emits `gdb.BreakpointEvent' which extends `gdb.StopEvent'. |
| |
| `gdb.BreakpointEvent' event indicates that one or more breakpoints |
| have been hit, and has the following attributes: |
| |
| -- Variable: BreakpointEvent.breakpoints |
| A sequence containing references to all the breakpoints (type |
| `gdb.Breakpoint') that were hit. *Note Breakpoints In |
| Python::, for details of the `gdb.Breakpoint' object. |
| |
| -- Variable: BreakpointEvent.breakpoint |
| A reference to the first breakpoint that was hit. This |
| function is maintained for backward compatibility and is now |
| deprecated in favor of the `gdb.BreakpointEvent.breakpoints' |
| attribute. |
| |
| `events.new_objfile' |
| Emits `gdb.NewObjFileEvent' which indicates that a new object file |
| has been loaded by GDB. `gdb.NewObjFileEvent' has one attribute: |
| |
| -- Variable: NewObjFileEvent.new_objfile |
| A reference to the object file (`gdb.Objfile') which has been |
| loaded. *Note Objfiles In Python::, for details of the |
| `gdb.Objfile' object. |
| |
| |
| |
| File: gdb.info, Node: Threads In Python, Next: Commands In Python, Prev: Events In Python, Up: Python API |
| |
| 23.2.2.14 Threads In Python |
| ........................... |
| |
| Python scripts can access information about, and manipulate inferior |
| threads controlled by GDB, via objects of the `gdb.InferiorThread' |
| class. |
| |
| The following thread-related functions are available in the `gdb' |
| module: |
| |
| -- Function: gdb.selected_thread () |
| This function returns the thread object for the selected thread. |
| If there is no selected thread, this will return `None'. |
| |
| A `gdb.InferiorThread' object has the following attributes: |
| |
| -- Variable: InferiorThread.name |
| The name of the thread. If the user specified a name using |
| `thread name', then this returns that name. Otherwise, if an |
| OS-supplied name is available, then it is returned. Otherwise, |
| this returns `None'. |
| |
| This attribute can be assigned to. The new value must be a string |
| object, which sets the new name, or `None', which removes any |
| user-specified thread name. |
| |
| -- Variable: InferiorThread.num |
| ID of the thread, as assigned by GDB. |
| |
| -- Variable: InferiorThread.ptid |
| ID of the thread, as assigned by the operating system. This |
| attribute is a tuple containing three integers. The first is the |
| Process ID (PID); the second is the Lightweight Process ID |
| (LWPID), and the third is the Thread ID (TID). Either the LWPID |
| or TID may be 0, which indicates that the operating system does |
| not use that identifier. |
| |
| A `gdb.InferiorThread' object has the following methods: |
| |
| -- Function: InferiorThread.is_valid () |
| Returns `True' if the `gdb.InferiorThread' object is valid, |
| `False' if not. A `gdb.InferiorThread' object will become invalid |
| if the thread exits, or the inferior that the thread belongs is |
| deleted. All other `gdb.InferiorThread' methods will throw an |
| exception if it is invalid at the time the method is called. |
| |
| -- Function: InferiorThread.switch () |
| This changes GDB's currently selected thread to the one represented |
| by this object. |
| |
| -- Function: InferiorThread.is_stopped () |
| Return a Boolean indicating whether the thread is stopped. |
| |
| -- Function: InferiorThread.is_running () |
| Return a Boolean indicating whether the thread is running. |
| |
| -- Function: InferiorThread.is_exited () |
| Return a Boolean indicating whether the thread is exited. |
| |
| |
| File: gdb.info, Node: Commands In Python, Next: Parameters In Python, Prev: Threads In Python, Up: Python API |
| |
| 23.2.2.15 Commands In Python |
| ............................ |
| |
| You can implement new GDB CLI commands in Python. A CLI command is |
| implemented using an instance of the `gdb.Command' class, most commonly |
| using a subclass. |
| |
| -- Function: Command.__init__ (name, COMMAND_CLASS [, COMPLETER_CLASS |
| [, PREFIX]]) |
| The object initializer for `Command' registers the new command |
| with GDB. This initializer is normally invoked from the subclass' |
| own `__init__' method. |
| |
| NAME is the name of the command. If NAME consists of multiple |
| words, then the initial words are looked for as prefix commands. |
| In this case, if one of the prefix commands does not exist, an |
| exception is raised. |
| |
| There is no support for multi-line commands. |
| |
| COMMAND_CLASS should be one of the `COMMAND_' constants defined |
| below. This argument tells GDB how to categorize the new command |
| in the help system. |
| |
| COMPLETER_CLASS is an optional argument. If given, it should be |
| one of the `COMPLETE_' constants defined below. This argument |
| tells GDB how to perform completion for this command. If not |
| given, GDB will attempt to complete using the object's `complete' |
| method (see below); if no such method is found, an error will |
| occur when completion is attempted. |
| |
| PREFIX is an optional argument. If `True', then the new command |
| is a prefix command; sub-commands of this command may be |
| registered. |
| |
| The help text for the new command is taken from the Python |
| documentation string for the command's class, if there is one. If |
| no documentation string is provided, the default value "This |
| command is not documented." is used. |
| |
| -- Function: Command.dont_repeat () |
| By default, a GDB command is repeated when the user enters a blank |
| line at the command prompt. A command can suppress this behavior |
| by invoking the `dont_repeat' method. This is similar to the user |
| command `dont-repeat', see *note dont-repeat: Define. |
| |
| -- Function: Command.invoke (argument, from_tty) |
| This method is called by GDB when this command is invoked. |
| |
| ARGUMENT is a string. It is the argument to the command, after |
| leading and trailing whitespace has been stripped. |
| |
| FROM_TTY is a boolean argument. When true, this means that the |
| command was entered by the user at the terminal; when false it |
| means that the command came from elsewhere. |
| |
| If this method throws an exception, it is turned into a GDB |
| `error' call. Otherwise, the return value is ignored. |
| |
| To break ARGUMENT up into an argv-like string use |
| `gdb.string_to_argv'. This function behaves identically to GDB's |
| internal argument lexer `buildargv'. It is recommended to use |
| this for consistency. Arguments are separated by spaces and may |
| be quoted. Example: |
| |
| print gdb.string_to_argv ("1 2\ \\\"3 '4 \"5' \"6 '7\"") |
| ['1', '2 "3', '4 "5', "6 '7"] |
| |
| |
| -- Function: Command.complete (text, word) |
| This method is called by GDB when the user attempts completion on |
| this command. All forms of completion are handled by this method, |
| that is, the <TAB> and <M-?> key bindings (*note Completion::), |
| and the `complete' command (*note complete: Help.). |
| |
| The arguments TEXT and WORD are both strings. TEXT holds the |
| complete command line up to the cursor's location. WORD holds the |
| last word of the command line; this is computed using a |
| word-breaking heuristic. |
| |
| The `complete' method can return several values: |
| * If the return value is a sequence, the contents of the |
| sequence are used as the completions. It is up to `complete' |
| to ensure that the contents actually do complete the word. A |
| zero-length sequence is allowed, it means that there were no |
| completions available. Only string elements of the sequence |
| are used; other elements in the sequence are ignored. |
| |
| * If the return value is one of the `COMPLETE_' constants |
| defined below, then the corresponding GDB-internal completion |
| function is invoked, and its result is used. |
| |
| * All other results are treated as though there were no |
| available completions. |
| |
| When a new command is registered, it must be declared as a member of |
| some general class of commands. This is used to classify top-level |
| commands in the on-line help system; note that prefix commands are not |
| listed under their own category but rather that of their top-level |
| command. The available classifications are represented by constants |
| defined in the `gdb' module: |
| |
| `gdb.COMMAND_NONE' |
| The command does not belong to any particular class. A command in |
| this category will not be displayed in any of the help categories. |
| |
| `gdb.COMMAND_RUNNING' |
| The command is related to running the inferior. For example, |
| `start', `step', and `continue' are in this category. Type `help |
| running' at the GDB prompt to see a list of commands in this |
| category. |
| |
| `gdb.COMMAND_DATA' |
| The command is related to data or variables. For example, `call', |
| `find', and `print' are in this category. Type `help data' at the |
| GDB prompt to see a list of commands in this category. |
| |
| `gdb.COMMAND_STACK' |
| The command has to do with manipulation of the stack. For example, |
| `backtrace', `frame', and `return' are in this category. Type |
| `help stack' at the GDB prompt to see a list of commands in this |
| category. |
| |
| `gdb.COMMAND_FILES' |
| This class is used for file-related commands. For example, |
| `file', `list' and `section' are in this category. Type `help |
| files' at the GDB prompt to see a list of commands in this |
| category. |
| |
| `gdb.COMMAND_SUPPORT' |
| This should be used for "support facilities", generally meaning |
| things that are useful to the user when interacting with GDB, but |
| not related to the state of the inferior. For example, `help', |
| `make', and `shell' are in this category. Type `help support' at |
| the GDB prompt to see a list of commands in this category. |
| |
| `gdb.COMMAND_STATUS' |
| The command is an `info'-related command, that is, related to the |
| state of GDB itself. For example, `info', `macro', and `show' are |
| in this category. Type `help status' at the GDB prompt to see a |
| list of commands in this category. |
| |
| `gdb.COMMAND_BREAKPOINTS' |
| The command has to do with breakpoints. For example, `break', |
| `clear', and `delete' are in this category. Type `help |
| breakpoints' at the GDB prompt to see a list of commands in this |
| category. |
| |
| `gdb.COMMAND_TRACEPOINTS' |
| The command has to do with tracepoints. For example, `trace', |
| `actions', and `tfind' are in this category. Type `help |
| tracepoints' at the GDB prompt to see a list of commands in this |
| category. |
| |
| `gdb.COMMAND_USER' |
| The command is a general purpose command for the user, and |
| typically does not fit in one of the other categories. Type `help |
| user-defined' at the GDB prompt to see a list of commands in this |
| category, as well as the list of gdb macros (*note Sequences::). |
| |
| `gdb.COMMAND_OBSCURE' |
| The command is only used in unusual circumstances, or is not of |
| general interest to users. For example, `checkpoint', `fork', and |
| `stop' are in this category. Type `help obscure' at the GDB |
| prompt to see a list of commands in this category. |
| |
| `gdb.COMMAND_MAINTENANCE' |
| The command is only useful to GDB maintainers. The `maintenance' |
| and `flushregs' commands are in this category. Type `help |
| internals' at the GDB prompt to see a list of commands in this |
| category. |
| |
| A new command can use a predefined completion function, either by |
| specifying it via an argument at initialization, or by returning it |
| from the `complete' method. These predefined completion constants are |
| all defined in the `gdb' module: |
| |
| `gdb.COMPLETE_NONE' |
| This constant means that no completion should be done. |
| |
| `gdb.COMPLETE_FILENAME' |
| This constant means that filename completion should be performed. |
| |
| `gdb.COMPLETE_LOCATION' |
| This constant means that location completion should be done. |
| *Note Specify Location::. |
| |
| `gdb.COMPLETE_COMMAND' |
| This constant means that completion should examine GDB command |
| names. |
| |
| `gdb.COMPLETE_SYMBOL' |
| This constant means that completion should be done using symbol |
| names as the source. |
| |
| `gdb.COMPLETE_EXPRESSION' |
| This constant means that completion should be done on expressions. |
| Often this means completing on symbol names, but some language |
| parsers also have support for completing on field names. |
| |
| The following code snippet shows how a trivial CLI command can be |
| implemented in Python: |
| |
| class HelloWorld (gdb.Command): |
| """Greet the whole world.""" |
| |
| def __init__ (self): |
| super (HelloWorld, self).__init__ ("hello-world", gdb.COMMAND_USER) |
| |
| def invoke (self, arg, from_tty): |
| print "Hello, World!" |
| |
| HelloWorld () |
| |
| The last line instantiates the class, and is necessary to trigger the |
| registration of the command with GDB. Depending on how the Python code |
| is read into GDB, you may need to import the `gdb' module explicitly. |
| |
| |
| File: gdb.info, Node: Parameters In Python, Next: Functions In Python, Prev: Commands In Python, Up: Python API |
| |
| 23.2.2.16 Parameters In Python |
| .............................. |
| |
| You can implement new GDB parameters using Python. A new parameter is |
| implemented as an instance of the `gdb.Parameter' class. |
| |
| Parameters are exposed to the user via the `set' and `show' |
| commands. *Note Help::. |
| |
| There are many parameters that already exist and can be set in GDB. |
| Two examples are: `set follow fork' and `set charset'. Setting these |
| parameters influences certain behavior in GDB. Similarly, you can |
| define parameters that can be used to influence behavior in custom |
| Python scripts and commands. |
| |
| -- Function: Parameter.__init__ (name, COMMAND-CLASS, PARAMETER-CLASS |
| [, ENUM-SEQUENCE]) |
| The object initializer for `Parameter' registers the new parameter |
| with GDB. This initializer is normally invoked from the subclass' |
| own `__init__' method. |
| |
| NAME is the name of the new parameter. If NAME consists of |
| multiple words, then the initial words are looked for as prefix |
| parameters. An example of this can be illustrated with the `set |
| print' set of parameters. If NAME is `print foo', then `print' |
| will be searched as the prefix parameter. In this case the |
| parameter can subsequently be accessed in GDB as `set print foo'. |
| |
| If NAME consists of multiple words, and no prefix parameter group |
| can be found, an exception is raised. |
| |
| COMMAND-CLASS should be one of the `COMMAND_' constants (*note |
| Commands In Python::). This argument tells GDB how to categorize |
| the new parameter in the help system. |
| |
| PARAMETER-CLASS should be one of the `PARAM_' constants defined |
| below. This argument tells GDB the type of the new parameter; |
| this information is used for input validation and completion. |
| |
| If PARAMETER-CLASS is `PARAM_ENUM', then ENUM-SEQUENCE must be a |
| sequence of strings. These strings represent the possible values |
| for the parameter. |
| |
| If PARAMETER-CLASS is not `PARAM_ENUM', then the presence of a |
| fourth argument will cause an exception to be thrown. |
| |
| The help text for the new parameter is taken from the Python |
| documentation string for the parameter's class, if there is one. |
| If there is no documentation string, a default value is used. |
| |
| -- Variable: Parameter.set_doc |
| If this attribute exists, and is a string, then its value is used |
| as the help text for this parameter's `set' command. The value is |
| examined when `Parameter.__init__' is invoked; subsequent changes |
| have no effect. |
| |
| -- Variable: Parameter.show_doc |
| If this attribute exists, and is a string, then its value is used |
| as the help text for this parameter's `show' command. The value is |
| examined when `Parameter.__init__' is invoked; subsequent changes |
| have no effect. |
| |
| -- Variable: Parameter.value |
| The `value' attribute holds the underlying value of the parameter. |
| It can be read and assigned to just as any other attribute. GDB |
| does validation when assignments are made. |
| |
| There are two methods that should be implemented in any `Parameter' |
| class. These are: |
| |
| -- Function: Parameter.get_set_string (self) |
| GDB will call this method when a PARAMETER's value has been |
| changed via the `set' API (for example, `set foo off'). The |
| `value' attribute has already been populated with the new value |
| and may be used in output. This method must return a string. |
| |
| -- Function: Parameter.get_show_string (self, svalue) |
| GDB will call this method when a PARAMETER's `show' API has been |
| invoked (for example, `show foo'). The argument `svalue' receives |
| the string representation of the current value. This method must |
| return a string. |
| |
| When a new parameter is defined, its type must be specified. The |
| available types are represented by constants defined in the `gdb' |
| module: |
| |
| `gdb.PARAM_BOOLEAN' |
| The value is a plain boolean. The Python boolean values, `True' |
| and `False' are the only valid values. |
| |
| `gdb.PARAM_AUTO_BOOLEAN' |
| The value has three possible states: true, false, and `auto'. In |
| Python, true and false are represented using boolean constants, and |
| `auto' is represented using `None'. |
| |
| `gdb.PARAM_UINTEGER' |
| The value is an unsigned integer. The value of 0 should be |
| interpreted to mean "unlimited". |
| |
| `gdb.PARAM_INTEGER' |
| The value is a signed integer. The value of 0 should be |
| interpreted to mean "unlimited". |
| |
| `gdb.PARAM_STRING' |
| The value is a string. When the user modifies the string, any |
| escape sequences, such as `\t', `\f', and octal escapes, are |
| translated into corresponding characters and encoded into the |
| current host charset. |
| |
| `gdb.PARAM_STRING_NOESCAPE' |
| The value is a string. When the user modifies the string, escapes |
| are passed through untranslated. |
| |
| `gdb.PARAM_OPTIONAL_FILENAME' |
| The value is a either a filename (a string), or `None'. |
| |
| `gdb.PARAM_FILENAME' |
| The value is a filename. This is just like |
| `PARAM_STRING_NOESCAPE', but uses file names for completion. |
| |
| `gdb.PARAM_ZINTEGER' |
| The value is an integer. This is like `PARAM_INTEGER', except 0 |
| is interpreted as itself. |
| |
| `gdb.PARAM_ENUM' |
| The value is a string, which must be one of a collection string |
| constants provided when the parameter is created. |
| |
| |
| File: gdb.info, Node: Functions In Python, Next: Progspaces In Python, Prev: Parameters In Python, Up: Python API |
| |
| 23.2.2.17 Writing new convenience functions |
| ........................................... |
| |
| You can implement new convenience functions (*note Convenience Vars::) |
| in Python. A convenience function is an instance of a subclass of the |
| class `gdb.Function'. |
| |
| -- Function: Function.__init__ (name) |
| The initializer for `Function' registers the new function with |
| GDB. The argument NAME is the name of the function, a string. |
| The function will be visible to the user as a convenience variable |
| of type `internal function', whose name is the same as the given |
| NAME. |
| |
| The documentation for the new function is taken from the |
| documentation string for the new class. |
| |
| -- Function: Function.invoke (*ARGS) |
| When a convenience function is evaluated, its arguments are |
| converted to instances of `gdb.Value', and then the function's |
| `invoke' method is called. Note that GDB does not predetermine |
| the arity of convenience functions. Instead, all available |
| arguments are passed to `invoke', following the standard Python |
| calling convention. In particular, a convenience function can |
| have default values for parameters without ill effect. |
| |
| The return value of this method is used as its value in the |
| enclosing expression. If an ordinary Python value is returned, it |
| is converted to a `gdb.Value' following the usual rules. |
| |
| The following code snippet shows how a trivial convenience function |
| can be implemented in Python: |
| |
| class Greet (gdb.Function): |
| """Return string to greet someone. |
| Takes a name as argument.""" |
| |
| def __init__ (self): |
| super (Greet, self).__init__ ("greet") |
| |
| def invoke (self, name): |
| return "Hello, %s!" % name.string () |
| |
| Greet () |
| |
| The last line instantiates the class, and is necessary to trigger the |
| registration of the function with GDB. Depending on how the Python |
| code is read into GDB, you may need to import the `gdb' module |
| explicitly. |
| |
| Now you can use the function in an expression: |
| |
| (gdb) print $greet("Bob") |
| $1 = "Hello, Bob!" |
| |
| |
| File: gdb.info, Node: Progspaces In Python, Next: Objfiles In Python, Prev: Functions In Python, Up: Python API |
| |
| 23.2.2.18 Program Spaces In Python |
| .................................. |
| |
| A program space, or "progspace", represents a symbolic view of an |
| address space. It consists of all of the objfiles of the program. |
| *Note Objfiles In Python::. *Note program spaces: Inferiors and |
| Programs, for more details about program spaces. |
| |
| The following progspace-related functions are available in the `gdb' |
| module: |
| |
| -- Function: gdb.current_progspace () |
| This function returns the program space of the currently selected |
| inferior. *Note Inferiors and Programs::. |
| |
| -- Function: gdb.progspaces () |
| Return a sequence of all the progspaces currently known to GDB. |
| |
| Each progspace is represented by an instance of the `gdb.Progspace' |
| class. |
| |
| -- Variable: Progspace.filename |
| The file name of the progspace as a string. |
| |
| -- Variable: Progspace.pretty_printers |
| The `pretty_printers' attribute is a list of functions. It is |
| used to look up pretty-printers. A `Value' is passed to each |
| function in order; if the function returns `None', then the search |
| continues. Otherwise, the return value should be an object which |
| is used to format the value. *Note Pretty Printing API::, for more |
| information. |
| |
| -- Variable: Progspace.type_printers |
| The `type_printers' attribute is a list of type printer objects. |
| *Note Type Printing API::, for more information. |
| |
| -- Variable: Progspace.frame_filters |
| The `frame_filters' attribute is a dictionary of frame filter |
| objects. *Note Frame Filter API::, for more information. |
| |
| |
| File: gdb.info, Node: Objfiles In Python, Next: Frames In Python, Prev: Progspaces In Python, Up: Python API |
| |
| 23.2.2.19 Objfiles In Python |
| ............................ |
| |
| GDB loads symbols for an inferior from various symbol-containing files |
| (*note Files::). These include the primary executable file, any shared |
| libraries used by the inferior, and any separate debug info files |
| (*note Separate Debug Files::). GDB calls these symbol-containing |
| files "objfiles". |
| |
| The following objfile-related functions are available in the `gdb' |
| module: |
| |
| -- Function: gdb.current_objfile () |
| When auto-loading a Python script (*note Python Auto-loading::), |
| GDB sets the "current objfile" to the corresponding objfile. This |
| function returns the current objfile. If there is no current |
| objfile, this function returns `None'. |
| |
| -- Function: gdb.objfiles () |
| Return a sequence of all the objfiles current known to GDB. *Note |
| Objfiles In Python::. |
| |
| Each objfile is represented by an instance of the `gdb.Objfile' |
| class. |
| |
| -- Variable: Objfile.filename |
| The file name of the objfile as a string. |
| |
| -- Variable: Objfile.pretty_printers |
| The `pretty_printers' attribute is a list of functions. It is |
| used to look up pretty-printers. A `Value' is passed to each |
| function in order; if the function returns `None', then the search |
| continues. Otherwise, the return value should be an object which |
| is used to format the value. *Note Pretty Printing API::, for more |
| information. |
| |
| -- Variable: Objfile.type_printers |
| The `type_printers' attribute is a list of type printer objects. |
| *Note Type Printing API::, for more information. |
| |
| -- Variable: Objfile.frame_filters |
| The `frame_filters' attribute is a dictionary of frame filter |
| objects. *Note Frame Filter API::, for more information. |
| |
| A `gdb.Objfile' object has the following methods: |
| |
| -- Function: Objfile.is_valid () |
| Returns `True' if the `gdb.Objfile' object is valid, `False' if |
| not. A `gdb.Objfile' object can become invalid if the object file |
| it refers to is not loaded in GDB any longer. All other |
| `gdb.Objfile' methods will throw an exception if it is invalid at |
| the time the method is called. |
| |
| |
| File: gdb.info, Node: Frames In Python, Next: Blocks In Python, Prev: Objfiles In Python, Up: Python API |
| |
| 23.2.2.20 Accessing inferior stack frames from Python. |
| ...................................................... |
| |
| When the debugged program stops, GDB is able to analyze its call stack |
| (*note Stack frames: Frames.). The `gdb.Frame' class represents a |
| frame in the stack. A `gdb.Frame' object is only valid while its |
| corresponding frame exists in the inferior's stack. If you try to use |
| an invalid frame object, GDB will throw a `gdb.error' exception (*note |
| Exception Handling::). |
| |
| Two `gdb.Frame' objects can be compared for equality with the `==' |
| operator, like: |
| |
| (gdb) python print gdb.newest_frame() == gdb.selected_frame () |
| True |
| |
| The following frame-related functions are available in the `gdb' |
| module: |
| |
| -- Function: gdb.selected_frame () |
| Return the selected frame object. (*note Selecting a Frame: |
| Selection.). |
| |
| -- Function: gdb.newest_frame () |
| Return the newest frame object for the selected thread. |
| |
| -- Function: gdb.frame_stop_reason_string (reason) |
| Return a string explaining the reason why GDB stopped unwinding |
| frames, as expressed by the given REASON code (an integer, see the |
| `unwind_stop_reason' method further down in this section). |
| |
| A `gdb.Frame' object has the following methods: |
| |
| -- Function: Frame.is_valid () |
| Returns true if the `gdb.Frame' object is valid, false if not. A |
| frame object can become invalid if the frame it refers to doesn't |
| exist anymore in the inferior. All `gdb.Frame' methods will throw |
| an exception if it is invalid at the time the method is called. |
| |
| -- Function: Frame.name () |
| Returns the function name of the frame, or `None' if it can't be |
| obtained. |
| |
| -- Function: Frame.architecture () |
| Returns the `gdb.Architecture' object corresponding to the frame's |
| architecture. *Note Architectures In Python::. |
| |
| -- Function: Frame.type () |
| Returns the type of the frame. The value can be one of: |
| `gdb.NORMAL_FRAME' |
| An ordinary stack frame. |
| |
| `gdb.DUMMY_FRAME' |
| A fake stack frame that was created by GDB when performing an |
| inferior function call. |
| |
| `gdb.INLINE_FRAME' |
| A frame representing an inlined function. The function was |
| inlined into a `gdb.NORMAL_FRAME' that is older than this one. |
| |
| `gdb.TAILCALL_FRAME' |
| A frame representing a tail call. *Note Tail Call Frames::. |
| |
| `gdb.SIGTRAMP_FRAME' |
| A signal trampoline frame. This is the frame created by the |
| OS when it calls into a signal handler. |
| |
| `gdb.ARCH_FRAME' |
| A fake stack frame representing a cross-architecture call. |
| |
| `gdb.SENTINEL_FRAME' |
| This is like `gdb.NORMAL_FRAME', but it is only used for the |
| newest frame. |
| |
| -- Function: Frame.unwind_stop_reason () |
| Return an integer representing the reason why it's not possible to |
| find more frames toward the outermost frame. Use |
| `gdb.frame_stop_reason_string' to convert the value returned by |
| this function to a string. The value can be one of: |
| |
| `gdb.FRAME_UNWIND_NO_REASON' |
| No particular reason (older frames should be available). |
| |
| `gdb.FRAME_UNWIND_NULL_ID' |
| The previous frame's analyzer returns an invalid result. |
| This is no longer used by GDB, and is kept only for backward |
| compatibility. |
| |
| `gdb.FRAME_UNWIND_OUTERMOST' |
| This frame is the outermost. |
| |
| `gdb.FRAME_UNWIND_UNAVAILABLE' |
| Cannot unwind further, because that would require knowing the |
| values of registers or memory that have not been collected. |
| |
| `gdb.FRAME_UNWIND_INNER_ID' |
| This frame ID looks like it ought to belong to a NEXT frame, |
| but we got it for a PREV frame. Normally, this is a sign of |
| unwinder failure. It could also indicate stack corruption. |
| |
| `gdb.FRAME_UNWIND_SAME_ID' |
| This frame has the same ID as the previous one. That means |
| that unwinding further would almost certainly give us another |
| frame with exactly the same ID, so break the chain. Normally, |
| this is a sign of unwinder failure. It could also indicate |
| stack corruption. |
| |
| `gdb.FRAME_UNWIND_NO_SAVED_PC' |
| The frame unwinder did not find any saved PC, but we needed |
| one to unwind further. |
| |
| `gdb.FRAME_UNWIND_FIRST_ERROR' |
| Any stop reason greater or equal to this value indicates some |
| kind of error. This special value facilitates writing code |
| that tests for errors in unwinding in a way that will work |
| correctly even if the list of the other values is modified in |
| future GDB versions. Using it, you could write: |
| reason = gdb.selected_frame().unwind_stop_reason () |
| reason_str = gdb.frame_stop_reason_string (reason) |
| if reason >= gdb.FRAME_UNWIND_FIRST_ERROR: |
| print "An error occured: %s" % reason_str |
| |
| |
| -- Function: Frame.pc () |
| Returns the frame's resume address. |
| |
| -- Function: Frame.block () |
| Return the frame's code block. *Note Blocks In Python::. |
| |
| -- Function: Frame.function () |
| Return the symbol for the function corresponding to this frame. |
| *Note Symbols In Python::. |
| |
| -- Function: Frame.older () |
| Return the frame that called this frame. |
| |
| -- Function: Frame.newer () |
| Return the frame called by this frame. |
| |
| -- Function: Frame.find_sal () |
| Return the frame's symtab and line object. *Note Symbol Tables In |
| Python::. |
| |
| -- Function: Frame.read_var (variable [, block]) |
| Return the value of VARIABLE in this frame. If the optional |
| argument BLOCK is provided, search for the variable from that |
| block; otherwise start at the frame's current block (which is |
| determined by the frame's current program counter). VARIABLE must |
| be a string or a `gdb.Symbol' object. BLOCK must be a `gdb.Block' |
| object. |
| |
| -- Function: Frame.select () |
| Set this frame to be the selected frame. *Note Examining the |
| Stack: Stack. |
| |
| |
| File: gdb.info, Node: Blocks In Python, Next: Symbols In Python, Prev: Frames In Python, Up: Python API |
| |
| 23.2.2.21 Accessing blocks from Python. |
| ....................................... |
| |
| In GDB, symbols are stored in blocks. A block corresponds roughly to a |
| scope in the source code. Blocks are organized hierarchically, and are |
| represented individually in Python as a `gdb.Block'. Blocks rely on |
| debugging information being available. |
| |
| A frame has a block. Please see *note Frames In Python::, for a more |
| in-depth discussion of frames. |
| |
| The outermost block is known as the "global block". The global |
| block typically holds public global variables and functions. |
| |
| The block nested just inside the global block is the "static block". |
| The static block typically holds file-scoped variables and functions. |
| |
| GDB provides a method to get a block's superblock, but there is |
| currently no way to examine the sub-blocks of a block, or to iterate |
| over all the blocks in a symbol table (*note Symbol Tables In Python::). |
| |
| Here is a short example that should help explain blocks: |
| |
| /* This is in the global block. */ |
| int global; |
| |
| /* This is in the static block. */ |
| static int file_scope; |
| |
| /* 'function' is in the global block, and 'argument' is |
| in a block nested inside of 'function'. */ |
| int function (int argument) |
| { |
| /* 'local' is in a block inside 'function'. It may or may |
| not be in the same block as 'argument'. */ |
| int local; |
| |
| { |
| /* 'inner' is in a block whose superblock is the one holding |
| 'local'. */ |
| int inner; |
| |
| /* If this call is expanded by the compiler, you may see |
| a nested block here whose function is 'inline_function' |
| and whose superblock is the one holding 'inner'. */ |
| inline_function (); |
| } |
| } |
| |
| A `gdb.Block' is iterable. The iterator returns the symbols (*note |
| Symbols In Python::) local to the block. Python programs should not |
| assume that a specific block object will always contain a given symbol, |
| since changes in GDB features and infrastructure may cause symbols move |
| across blocks in a symbol table. |
| |
| The following block-related functions are available in the `gdb' |
| module: |
| |
| -- Function: gdb.block_for_pc (pc) |
| Return the innermost `gdb.Block' containing the given PC value. |
| If the block cannot be found for the PC value specified, the |
| function will return `None'. |
| |
| A `gdb.Block' object has the following methods: |
| |
| -- Function: Block.is_valid () |
| Returns `True' if the `gdb.Block' object is valid, `False' if not. |
| A block object can become invalid if the block it refers to |
| doesn't exist anymore in the inferior. All other `gdb.Block' |
| methods will throw an exception if it is invalid at the time the |
| method is called. The block's validity is also checked during |
| iteration over symbols of the block. |
| |
| A `gdb.Block' object has the following attributes: |
| |
| -- Variable: Block.start |
| The start address of the block. This attribute is not writable. |
| |
| -- Variable: Block.end |
| The end address of the block. This attribute is not writable. |
| |
| -- Variable: Block.function |
| The name of the block represented as a `gdb.Symbol'. If the block |
| is not named, then this attribute holds `None'. This attribute is |
| not writable. |
| |
| For ordinary function blocks, the superblock is the static block. |
| However, you should note that it is possible for a function block |
| to have a superblock that is not the static block - for instance |
| this happens for an inlined function. |
| |
| -- Variable: Block.superblock |
| The block containing this block. If this parent block does not |
| exist, this attribute holds `None'. This attribute is not |
| writable. |
| |
| -- Variable: Block.global_block |
| The global block associated with this block. This attribute is not |
| writable. |
| |
| -- Variable: Block.static_block |
| The static block associated with this block. This attribute is not |
| writable. |
| |
| -- Variable: Block.is_global |
| `True' if the `gdb.Block' object is a global block, `False' if |
| not. This attribute is not writable. |
| |
| -- Variable: Block.is_static |
| `True' if the `gdb.Block' object is a static block, `False' if |
| not. This attribute is not writable. |
| |
| |
| File: gdb.info, Node: Symbols In Python, Next: Symbol Tables In Python, Prev: Blocks In Python, Up: Python API |
| |
| 23.2.2.22 Python representation of Symbols. |
| ........................................... |
| |
| GDB represents every variable, function and type as an entry in a |
| symbol table. *Note Examining the Symbol Table: Symbols. Similarly, |
| Python represents these symbols in GDB with the `gdb.Symbol' object. |
| |
| The following symbol-related functions are available in the `gdb' |
| module: |
| |
| -- Function: gdb.lookup_symbol (name [, block [, domain]]) |
| This function searches for a symbol by name. The search scope can |
| be restricted to the parameters defined in the optional domain and |
| block arguments. |
| |
| NAME is the name of the symbol. It must be a string. The |
| optional BLOCK argument restricts the search to symbols visible in |
| that BLOCK. The BLOCK argument must be a `gdb.Block' object. If |
| omitted, the block for the current frame is used. The optional |
| DOMAIN argument restricts the search to the domain type. The |
| DOMAIN argument must be a domain constant defined in the `gdb' |
| module and described later in this chapter. |
| |
| The result is a tuple of two elements. The first element is a |
| `gdb.Symbol' object or `None' if the symbol is not found. If the |
| symbol is found, the second element is `True' if the symbol is a |
| field of a method's object (e.g., `this' in C++), otherwise it is |
| `False'. If the symbol is not found, the second element is |
| `False'. |
| |
| -- Function: gdb.lookup_global_symbol (name [, domain]) |
| This function searches for a global symbol by name. The search |
| scope can be restricted to by the domain argument. |
| |
| NAME is the name of the symbol. It must be a string. The |
| optional DOMAIN argument restricts the search to the domain type. |
| The DOMAIN argument must be a domain constant defined in the `gdb' |
| module and described later in this chapter. |
| |
| The result is a `gdb.Symbol' object or `None' if the symbol is not |
| found. |
| |
| A `gdb.Symbol' object has the following attributes: |
| |
| -- Variable: Symbol.type |
| The type of the symbol or `None' if no type is recorded. This |
| attribute is represented as a `gdb.Type' object. *Note Types In |
| Python::. This attribute is not writable. |
| |
| -- Variable: Symbol.symtab |
| The symbol table in which the symbol appears. This attribute is |
| represented as a `gdb.Symtab' object. *Note Symbol Tables In |
| Python::. This attribute is not writable. |
| |
| -- Variable: Symbol.line |
| The line number in the source code at which the symbol was defined. |
| This is an integer. |
| |
| -- Variable: Symbol.name |
| The name of the symbol as a string. This attribute is not |
| writable. |
| |
| -- Variable: Symbol.linkage_name |
| The name of the symbol, as used by the linker (i.e., may be |
| mangled). This attribute is not writable. |
| |
| -- Variable: Symbol.print_name |
| The name of the symbol in a form suitable for output. This is |
| either `name' or `linkage_name', depending on whether the user |
| asked GDB to display demangled or mangled names. |
| |
| -- Variable: Symbol.addr_class |
| The address class of the symbol. This classifies how to find the |
| value of a symbol. Each address class is a constant defined in the |
| `gdb' module and described later in this chapter. |
| |
| -- Variable: Symbol.needs_frame |
| This is `True' if evaluating this symbol's value requires a frame |
| (*note Frames In Python::) and `False' otherwise. Typically, |
| local variables will require a frame, but other symbols will not. |
| |
| -- Variable: Symbol.is_argument |
| `True' if the symbol is an argument of a function. |
| |
| -- Variable: Symbol.is_constant |
| `True' if the symbol is a constant. |
| |
| -- Variable: Symbol.is_function |
| `True' if the symbol is a function or a method. |
| |
| -- Variable: Symbol.is_variable |
| `True' if the symbol is a variable. |
| |
| A `gdb.Symbol' object has the following methods: |
| |
| -- Function: Symbol.is_valid () |
| Returns `True' if the `gdb.Symbol' object is valid, `False' if |
| not. A `gdb.Symbol' object can become invalid if the symbol it |
| refers to does not exist in GDB any longer. All other |
| `gdb.Symbol' methods will throw an exception if it is invalid at |
| the time the method is called. |
| |
| -- Function: Symbol.value ([frame]) |
| Compute the value of the symbol, as a `gdb.Value'. For functions, |
| this computes the address of the function, cast to the appropriate |
| type. If the symbol requires a frame in order to compute its |
| value, then FRAME must be given. If FRAME is not given, or if |
| FRAME is invalid, then this method will throw an exception. |
| |
| The available domain categories in `gdb.Symbol' are represented as |
| constants in the `gdb' module: |
| |
| `gdb.SYMBOL_UNDEF_DOMAIN' |
| This is used when a domain has not been discovered or none of the |
| following domains apply. This usually indicates an error either |
| in the symbol information or in GDB's handling of symbols. |
| |
| `gdb.SYMBOL_VAR_DOMAIN' |
| This domain contains variables, function names, typedef names and |
| enum type values. |
| |
| `gdb.SYMBOL_STRUCT_DOMAIN' |
| This domain holds struct, union and enum type names. |
| |
| `gdb.SYMBOL_LABEL_DOMAIN' |
| This domain contains names of labels (for gotos). |
| |
| `gdb.SYMBOL_VARIABLES_DOMAIN' |
| This domain holds a subset of the `SYMBOLS_VAR_DOMAIN'; it |
| contains everything minus functions and types. |
| |
| `gdb.SYMBOL_FUNCTION_DOMAIN' |
| This domain contains all functions. |
| |
| `gdb.SYMBOL_TYPES_DOMAIN' |
| This domain contains all types. |
| |
| The available address class categories in `gdb.Symbol' are |
| represented as constants in the `gdb' module: |
| |
| `gdb.SYMBOL_LOC_UNDEF' |
| If this is returned by address class, it indicates an error either |
| in the symbol information or in GDB's handling of symbols. |
| |
| `gdb.SYMBOL_LOC_CONST' |
| Value is constant int. |
| |
| `gdb.SYMBOL_LOC_STATIC' |
| Value is at a fixed address. |
| |
| `gdb.SYMBOL_LOC_REGISTER' |
| Value is in a register. |
| |
| `gdb.SYMBOL_LOC_ARG' |
| Value is an argument. This value is at the offset stored within |
| the symbol inside the frame's argument list. |
| |
| `gdb.SYMBOL_LOC_REF_ARG' |
| Value address is stored in the frame's argument list. Just like |
| `LOC_ARG' except that the value's address is stored at the offset, |
| not the value itself. |
| |
| `gdb.SYMBOL_LOC_REGPARM_ADDR' |
| Value is a specified register. Just like `LOC_REGISTER' except |
| the register holds the address of the argument instead of the |
| argument itself. |
| |
| `gdb.SYMBOL_LOC_LOCAL' |
| Value is a local variable. |
| |
| `gdb.SYMBOL_LOC_TYPEDEF' |
| Value not used. Symbols in the domain `SYMBOL_STRUCT_DOMAIN' all |
| have this class. |
| |
| `gdb.SYMBOL_LOC_BLOCK' |
| Value is a block. |
| |
| `gdb.SYMBOL_LOC_CONST_BYTES' |
| Value is a byte-sequence. |
| |
| `gdb.SYMBOL_LOC_UNRESOLVED' |
| Value is at a fixed address, but the address of the variable has |
| to be determined from the minimal symbol table whenever the |
| variable is referenced. |
| |
| `gdb.SYMBOL_LOC_OPTIMIZED_OUT' |
| The value does not actually exist in the program. |
| |
| `gdb.SYMBOL_LOC_COMPUTED' |
| The value's address is a computed location. |
| |
| |
| File: gdb.info, Node: Symbol Tables In Python, Next: Line Tables In Python, Prev: Symbols In Python, Up: Python API |
| |
| 23.2.2.23 Symbol table representation in Python. |
| ................................................ |
| |
| Access to symbol table data maintained by GDB on the inferior is |
| exposed to Python via two objects: `gdb.Symtab_and_line' and |
| `gdb.Symtab'. Symbol table and line data for a frame is returned from |
| the `find_sal' method in `gdb.Frame' object. *Note Frames In Python::. |
| |
| For more information on GDB's symbol table management, see *note |
| Examining the Symbol Table: Symbols, for more information. |
| |
| A `gdb.Symtab_and_line' object has the following attributes: |
| |
| -- Variable: Symtab_and_line.symtab |
| The symbol table object (`gdb.Symtab') for this frame. This |
| attribute is not writable. |
| |
| -- Variable: Symtab_and_line.pc |
| Indicates the start of the address range occupied by code for the |
| current source line. This attribute is not writable. |
| |
| -- Variable: Symtab_and_line.last |
| Indicates the end of the address range occupied by code for the |
| current source line. This attribute is not writable. |
| |
| -- Variable: Symtab_and_line.line |
| Indicates the current line number for this object. This attribute |
| is not writable. |
| |
| A `gdb.Symtab_and_line' object has the following methods: |
| |
| -- Function: Symtab_and_line.is_valid () |
| Returns `True' if the `gdb.Symtab_and_line' object is valid, |
| `False' if not. A `gdb.Symtab_and_line' object can become invalid |
| if the Symbol table and line object it refers to does not exist in |
| GDB any longer. All other `gdb.Symtab_and_line' methods will |
| throw an exception if it is invalid at the time the method is |
| called. |
| |
| A `gdb.Symtab' object has the following attributes: |
| |
| -- Variable: Symtab.filename |
| The symbol table's source filename. This attribute is not |
| writable. |
| |
| -- Variable: Symtab.objfile |
| The symbol table's backing object file. *Note Objfiles In |
| Python::. This attribute is not writable. |
| |
| A `gdb.Symtab' object has the following methods: |
| |
| -- Function: Symtab.is_valid () |
| Returns `True' if the `gdb.Symtab' object is valid, `False' if |
| not. A `gdb.Symtab' object can become invalid if the symbol table |
| it refers to does not exist in GDB any longer. All other |
| `gdb.Symtab' methods will throw an exception if it is invalid at |
| the time the method is called. |
| |
| -- Function: Symtab.fullname () |
| Return the symbol table's source absolute file name. |
| |
| -- Function: Symtab.global_block () |
| Return the global block of the underlying symbol table. *Note |
| Blocks In Python::. |
| |
| -- Function: Symtab.static_block () |
| Return the static block of the underlying symbol table. *Note |
| Blocks In Python::. |
| |
| -- Function: Symtab.linetable () |
| Return the line table associated with the symbol table. *Note |
| Line Tables In Python::. |
| |
| |
| File: gdb.info, Node: Line Tables In Python, Next: Breakpoints In Python, Prev: Symbol Tables In Python, Up: Python API |
| |
| 23.2.2.24 Manipulating line tables using Python |
| ............................................... |
| |
| Python code can request and inspect line table information from a |
| symbol table that is loaded in GDB. A line table is a mapping of |
| source lines to their executable locations in memory. To acquire the |
| line table information for a particular symbol table, use the |
| `linetable' function (*note Symbol Tables In Python::). |
| |
| A `gdb.LineTable' is iterable. The iterator returns |
| `LineTableEntry' objects that correspond to the source line and address |
| for each line table entry. `LineTableEntry' objects have the following |
| attributes: |
| |
| -- Variable: LineTableEntry.line |
| The source line number for this line table entry. This number |
| corresponds to the actual line of source. This attribute is not |
| writable. |
| |
| -- Variable: LineTableEntry.pc |
| The address that is associated with the line table entry where the |
| executable code for that source line resides in memory. This |
| attribute is not writable. |
| |
| As there can be multiple addresses for a single source line, you may |
| receive multiple `LineTableEntry' objects with matching `line' |
| attributes, but with different `pc' attributes. The iterator is sorted |
| in ascending `pc' order. Here is a small example illustrating |
| iterating over a line table. |
| |
| symtab = gdb.selected_frame().find_sal().symtab |
| linetable = symtab.linetable() |
| for line in linetable: |
| print "Line: "+str(line.line)+" Address: "+hex(line.pc) |
| |
| This will have the following output: |
| |
| Line: 33 Address: 0x4005c8L |
| Line: 37 Address: 0x4005caL |
| Line: 39 Address: 0x4005d2L |
| Line: 40 Address: 0x4005f8L |
| Line: 42 Address: 0x4005ffL |
| Line: 44 Address: 0x400608L |
| Line: 42 Address: 0x40060cL |
| Line: 45 Address: 0x400615L |
| |
| In addition to being able to iterate over a `LineTable', it also has |
| the following direct access methods: |
| |
| -- Function: LineTable.line (line) |
| Return a Python `Tuple' of `LineTableEntry' objects for any |
| entries in the line table for the given LINE. LINE refers to the |
| source code line. If there are no entries for that source code |
| LINE, the Python `None' is returned. |
| |
| -- Function: LineTable.has_line (line) |
| Return a Python `Boolean' indicating whether there is an entry in |
| the line table for this source line. Return `True' if an entry is |
| found, or `False' if not. |
| |
| -- Function: LineTable.source_lines () |
| Return a Python `List' of the source line numbers in the symbol |
| table. Only lines with executable code locations are returned. |
| The contents of the `List' will just be the source line entries |
| represented as Python `Long' values. |
| |
| |
| File: gdb.info, Node: Breakpoints In Python, Next: Finish Breakpoints in Python, Prev: Line Tables In Python, Up: Python API |
| |
| 23.2.2.25 Manipulating breakpoints using Python |
| ............................................... |
| |
| Python code can manipulate breakpoints via the `gdb.Breakpoint' class. |
| |
| -- Function: Breakpoint.__init__ (spec [, type [, wp_class [,internal |
| [,temporary]]]]) |
| Create a new breakpoint. SPEC is a string naming the location of |
| the breakpoint, or an expression that defines a watchpoint. The |
| contents can be any location recognized by the `break' command, or |
| in the case of a watchpoint, by the `watch' command. The optional |
| TYPE denotes the breakpoint to create from the types defined later |
| in this chapter. This argument can be either: `gdb.BP_BREAKPOINT' |
| or `gdb.BP_WATCHPOINT'. TYPE defaults to `gdb.BP_BREAKPOINT'. |
| The optional INTERNAL argument allows the breakpoint to become |
| invisible to the user. The breakpoint will neither be reported |
| when created, nor will it be listed in the output from `info |
| breakpoints' (but will be listed with the `maint info breakpoints' |
| command). The optional TEMPORARY argument makes the breakpoint a |
| temporary breakpoint. Temporary breakpoints are deleted after |
| they have been hit. Any further access to the Python breakpoint |
| after it has been hit will result in a runtime error (as that |
| breakpoint has now been automatically deleted). The optional |
| WP_CLASS argument defines the class of watchpoint to create, if |
| TYPE is `gdb.BP_WATCHPOINT'. If a watchpoint class is not |
| provided, it is assumed to be a `gdb.WP_WRITE' class. |
| |
| -- Function: Breakpoint.stop (self) |
| The `gdb.Breakpoint' class can be sub-classed and, in particular, |
| you may choose to implement the `stop' method. If this method is |
| defined in a sub-class of `gdb.Breakpoint', it will be called when |
| the inferior reaches any location of a breakpoint which |
| instantiates that sub-class. If the method returns `True', the |
| inferior will be stopped at the location of the breakpoint, |
| otherwise the inferior will continue. |
| |
| If there are multiple breakpoints at the same location with a |
| `stop' method, each one will be called regardless of the return |
| status of the previous. This ensures that all `stop' methods have |
| a chance to execute at that location. In this scenario if one of |
| the methods returns `True' but the others return `False', the |
| inferior will still be stopped. |
| |
| You should not alter the execution state of the inferior (i.e., |
| step, next, etc.), alter the current frame context (i.e., change |
| the current active frame), or alter, add or delete any breakpoint. |
| As a general rule, you should not alter any data within GDB or the |
| inferior at this time. |
| |
| Example `stop' implementation: |
| |
| class MyBreakpoint (gdb.Breakpoint): |
| def stop (self): |
| inf_val = gdb.parse_and_eval("foo") |
| if inf_val == 3: |
| return True |
| return False |
| |
| The available watchpoint types represented by constants are defined |
| in the `gdb' module: |
| |
| `gdb.WP_READ' |
| Read only watchpoint. |
| |
| `gdb.WP_WRITE' |
| Write only watchpoint. |
| |
| `gdb.WP_ACCESS' |
| Read/Write watchpoint. |
| |
| -- Function: Breakpoint.is_valid () |
| Return `True' if this `Breakpoint' object is valid, `False' |
| otherwise. A `Breakpoint' object can become invalid if the user |
| deletes the breakpoint. In this case, the object still exists, |
| but the underlying breakpoint does not. In the cases of |
| watchpoint scope, the watchpoint remains valid even if execution |
| of the inferior leaves the scope of that watchpoint. |
| |
| -- Function: Breakpoint.delete |
| Permanently deletes the GDB breakpoint. This also invalidates the |
| Python `Breakpoint' object. Any further access to this object's |
| attributes or methods will raise an error. |
| |
| -- Variable: Breakpoint.enabled |
| This attribute is `True' if the breakpoint is enabled, and `False' |
| otherwise. This attribute is writable. |
| |
| -- Variable: Breakpoint.silent |
| This attribute is `True' if the breakpoint is silent, and `False' |
| otherwise. This attribute is writable. |
| |
| Note that a breakpoint can also be silent if it has commands and |
| the first command is `silent'. This is not reported by the |
| `silent' attribute. |
| |
| -- Variable: Breakpoint.thread |
| If the breakpoint is thread-specific, this attribute holds the |
| thread id. If the breakpoint is not thread-specific, this |
| attribute is `None'. This attribute is writable. |
| |
| -- Variable: Breakpoint.task |
| If the breakpoint is Ada task-specific, this attribute holds the |
| Ada task id. If the breakpoint is not task-specific (or the |
| underlying language is not Ada), this attribute is `None'. This |
| attribute is writable. |
| |
| -- Variable: Breakpoint.ignore_count |
| This attribute holds the ignore count for the breakpoint, an |
| integer. This attribute is writable. |
| |
| -- Variable: Breakpoint.number |
| This attribute holds the breakpoint's number -- the identifier |
| used by the user to manipulate the breakpoint. This attribute is |
| not writable. |
| |
| -- Variable: Breakpoint.type |
| This attribute holds the breakpoint's type -- the identifier used |
| to determine the actual breakpoint type or use-case. This |
| attribute is not writable. |
| |
| -- Variable: Breakpoint.visible |
| This attribute tells whether the breakpoint is visible to the user |
| when set, or when the `info breakpoints' command is run. This |
| attribute is not writable. |
| |
| -- Variable: Breakpoint.temporary |
| This attribute indicates whether the breakpoint was created as a |
| temporary breakpoint. Temporary breakpoints are automatically |
| deleted after that breakpoint has been hit. Access to this |
| attribute, and all other attributes and functions other than the |
| `is_valid' function, will result in an error after the breakpoint |
| has been hit (as it has been automatically deleted). This |
| attribute is not writable. |
| |
| The available types are represented by constants defined in the `gdb' |
| module: |
| |
| `gdb.BP_BREAKPOINT' |
| Normal code breakpoint. |
| |
| `gdb.BP_WATCHPOINT' |
| Watchpoint breakpoint. |
| |
| `gdb.BP_HARDWARE_WATCHPOINT' |
| Hardware assisted watchpoint. |
| |
| `gdb.BP_READ_WATCHPOINT' |
| Hardware assisted read watchpoint. |
| |
| `gdb.BP_ACCESS_WATCHPOINT' |
| Hardware assisted access watchpoint. |
| |
| -- Variable: Breakpoint.hit_count |
| This attribute holds the hit count for the breakpoint, an integer. |
| This attribute is writable, but currently it can only be set to |
| zero. |
| |
| -- Variable: Breakpoint.location |
| This attribute holds the location of the breakpoint, as specified |
| by the user. It is a string. If the breakpoint does not have a |
| location (that is, it is a watchpoint) the attribute's value is |
| `None'. This attribute is not writable. |
| |
| -- Variable: Breakpoint.expression |
| This attribute holds a breakpoint expression, as specified by the |
| user. It is a string. If the breakpoint does not have an |
| expression (the breakpoint is not a watchpoint) the attribute's |
| value is `None'. This attribute is not writable. |
| |
| -- Variable: Breakpoint.condition |
| This attribute holds the condition of the breakpoint, as specified |
| by the user. It is a string. If there is no condition, this |
| attribute's value is `None'. This attribute is writable. |
| |
| -- Variable: Breakpoint.commands |
| This attribute holds the commands attached to the breakpoint. If |
| there are commands, this attribute's value is a string holding all |
| the commands, separated by newlines. If there are no commands, |
| this attribute is `None'. This attribute is not writable. |
| |
| |
| File: gdb.info, Node: Finish Breakpoints in Python, Next: Lazy Strings In Python, Prev: Breakpoints In Python, Up: Python API |
| |
| 23.2.2.26 Finish Breakpoints |
| ............................ |
| |
| A finish breakpoint is a temporary breakpoint set at the return address |
| of a frame, based on the `finish' command. `gdb.FinishBreakpoint' |
| extends `gdb.Breakpoint'. The underlying breakpoint will be disabled |
| and deleted when the execution will run out of the breakpoint scope |
| (i.e. `Breakpoint.stop' or `FinishBreakpoint.out_of_scope' triggered). |
| Finish breakpoints are thread specific and must be create with the right |
| thread selected. |
| |
| -- Function: FinishBreakpoint.__init__ ([frame] [, internal]) |
| Create a finish breakpoint at the return address of the `gdb.Frame' |
| object FRAME. If FRAME is not provided, this defaults to the |
| newest frame. The optional INTERNAL argument allows the |
| breakpoint to become invisible to the user. *Note Breakpoints In |
| Python::, for further details about this argument. |
| |
| -- Function: FinishBreakpoint.out_of_scope (self) |
| In some circumstances (e.g. `longjmp', C++ exceptions, GDB |
| `return' command, ...), a function may not properly terminate, and |
| thus never hit the finish breakpoint. When GDB notices such a |
| situation, the `out_of_scope' callback will be triggered. |
| |
| You may want to sub-class `gdb.FinishBreakpoint' and override this |
| method: |
| |
| class MyFinishBreakpoint (gdb.FinishBreakpoint) |
| def stop (self): |
| print "normal finish" |
| return True |
| |
| def out_of_scope (): |
| print "abnormal finish" |
| |
| -- Variable: FinishBreakpoint.return_value |
| When GDB is stopped at a finish breakpoint and the frame used to |
| build the `gdb.FinishBreakpoint' object had debug symbols, this |
| attribute will contain a `gdb.Value' object corresponding to the |
| return value of the function. The value will be `None' if the |
| function return type is `void' or if the return value was not |
| computable. This attribute is not writable. |
| |
| |
| File: gdb.info, Node: Lazy Strings In Python, Next: Architectures In Python, Prev: Finish Breakpoints in Python, Up: Python API |
| |
| 23.2.2.27 Python representation of lazy strings. |
| ................................................ |
| |
| A "lazy string" is a string whose contents is not retrieved or encoded |
| until it is needed. |
| |
| A `gdb.LazyString' is represented in GDB as an `address' that points |
| to a region of memory, an `encoding' that will be used to encode that |
| region of memory, and a `length' to delimit the region of memory that |
| represents the string. The difference between a `gdb.LazyString' and a |
| string wrapped within a `gdb.Value' is that a `gdb.LazyString' will be |
| treated differently by GDB when printing. A `gdb.LazyString' is |
| retrieved and encoded during printing, while a `gdb.Value' wrapping a |
| string is immediately retrieved and encoded on creation. |
| |
| A `gdb.LazyString' object has the following functions: |
| |
| -- Function: LazyString.value () |
| Convert the `gdb.LazyString' to a `gdb.Value'. This value will |
| point to the string in memory, but will lose all the delayed |
| retrieval, encoding and handling that GDB applies to a |
| `gdb.LazyString'. |
| |
| -- Variable: LazyString.address |
| This attribute holds the address of the string. This attribute is |
| not writable. |
| |
| -- Variable: LazyString.length |
| This attribute holds the length of the string in characters. If |
| the length is -1, then the string will be fetched and encoded up |
| to the first null of appropriate width. This attribute is not |
| writable. |
| |
| -- Variable: LazyString.encoding |
| This attribute holds the encoding that will be applied to the |
| string when the string is printed by GDB. If the encoding is not |
| set, or contains an empty string, then GDB will select the most |
| appropriate encoding when the string is printed. This attribute |
| is not writable. |
| |
| -- Variable: LazyString.type |
| This attribute holds the type that is represented by the lazy |
| string's type. For a lazy string this will always be a pointer |
| type. To resolve this to the lazy string's character type, use |
| the type's `target' method. *Note Types In Python::. This |
| attribute is not writable. |
| |
| |
| File: gdb.info, Node: Architectures In Python, Prev: Lazy Strings In Python, Up: Python API |
| |
| 23.2.2.28 Python representation of architectures |
| ................................................ |
| |
| GDB uses architecture specific parameters and artifacts in a number of |
| its various computations. An architecture is represented by an |
| instance of the `gdb.Architecture' class. |
| |
| A `gdb.Architecture' class has the following methods: |
| |
| -- Function: Architecture.name () |
| Return the name (string value) of the architecture. |
| |
| -- Function: Architecture.disassemble (START_PC [, END_PC [, COUNT]]) |
| Return a list of disassembled instructions starting from the memory |
| address START_PC. The optional arguments END_PC and COUNT |
| determine the number of instructions in the returned list. If |
| both the optional arguments END_PC and COUNT are specified, then a |
| list of at most COUNT disassembled instructions whose start |
| address falls in the closed memory address interval from START_PC |
| to END_PC are returned. If END_PC is not specified, but COUNT is |
| specified, then COUNT number of instructions starting from the |
| address START_PC are returned. If COUNT is not specified but |
| END_PC is specified, then all instructions whose start address |
| falls in the closed memory address interval from START_PC to |
| END_PC are returned. If neither END_PC nor COUNT are specified, |
| then a single instruction at START_PC is returned. For all of |
| these cases, each element of the returned list is a Python `dict' |
| with the following string keys: |
| |
| `addr' |
| The value corresponding to this key is a Python long integer |
| capturing the memory address of the instruction. |
| |
| `asm' |
| The value corresponding to this key is a string value which |
| represents the instruction with assembly language mnemonics. |
| The assembly language flavor used is the same as that |
| specified by the current CLI variable `disassembly-flavor'. |
| *Note Machine Code::. |
| |
| `length' |
| The value corresponding to this key is the length (integer |
| value) of the instruction in bytes. |
| |
| |
| |
| File: gdb.info, Node: Python Auto-loading, Next: Python modules, Prev: Python API, Up: Python |
| |
| 23.2.3 Python Auto-loading |
| -------------------------- |
| |
| When a new object file is read (for example, due to the `file' command, |
| or because the inferior has loaded a shared library), GDB will look for |
| Python support scripts in several ways: `OBJFILE-gdb.py' (*note |
| objfile-gdb.py file::) and `.debug_gdb_scripts' section (*note |
| dotdebug_gdb_scripts section::). |
| |
| The auto-loading feature is useful for supplying application-specific |
| debugging commands and scripts. |
| |
| Auto-loading can be enabled or disabled, and the list of auto-loaded |
| scripts can be printed. |
| |
| `set auto-load python-scripts [on|off]' |
| Enable or disable the auto-loading of Python scripts. |
| |
| `show auto-load python-scripts' |
| Show whether auto-loading of Python scripts is enabled or disabled. |
| |
| `info auto-load python-scripts [REGEXP]' |
| Print the list of all Python scripts that GDB auto-loaded. |
| |
| Also printed is the list of Python scripts that were mentioned in |
| the `.debug_gdb_scripts' section and were not found (*note |
| dotdebug_gdb_scripts section::). This is useful because their |
| names are not printed when GDB tries to load them and fails. |
| There may be many of them, and printing an error message for each |
| one is problematic. |
| |
| If REGEXP is supplied only Python scripts with matching names are |
| printed. |
| |
| Example: |
| |
| (gdb) info auto-load python-scripts |
| Loaded Script |
| Yes py-section-script.py |
| full name: /tmp/py-section-script.py |
| No my-foo-pretty-printers.py |
| |
| When reading an auto-loaded file, GDB sets the "current objfile". |
| This is available via the `gdb.current_objfile' function (*note |
| Objfiles In Python::). This can be useful for registering |
| objfile-specific pretty-printers and frame-filters. |
| |
| * Menu: |
| |
| * objfile-gdb.py file:: The `OBJFILE-gdb.py' file |
| * dotdebug_gdb_scripts section:: The `.debug_gdb_scripts' section |
| * Which flavor to choose?:: |
| |
| |
| File: gdb.info, Node: objfile-gdb.py file, Next: dotdebug_gdb_scripts section, Up: Python Auto-loading |
| |
| 23.2.3.1 The `OBJFILE-gdb.py' file |
| .................................. |
| |
| When a new object file is read, GDB looks for a file named |
| `OBJFILE-gdb.py' (we call it SCRIPT-NAME below), where OBJFILE is the |
| object file's real name, formed by ensuring that the file name is |
| absolute, following all symlinks, and resolving `.' and `..' |
| components. If this file exists and is readable, GDB will evaluate it |
| as a Python script. |
| |
| If this file does not exist, then GDB will look for SCRIPT-NAME file |
| in all of the directories as specified below. |
| |
| Note that loading of this script file also requires accordingly |
| configured `auto-load safe-path' (*note Auto-loading safe path::). |
| |
| For object files using `.exe' suffix GDB tries to load first the |
| scripts normally according to its `.exe' filename. But if no scripts |
| are found GDB also tries script filenames matching the object file |
| without its `.exe' suffix. This `.exe' stripping is case insensitive |
| and it is attempted on any platform. This makes the script filenames |
| compatible between Unix and MS-Windows hosts. |
| |
| `set auto-load scripts-directory [DIRECTORIES]' |
| Control GDB auto-loaded scripts location. Multiple directory |
| entries may be delimited by the host platform path separator in use |
| (`:' on Unix, `;' on MS-Windows and MS-DOS). |
| |
| Each entry here needs to be covered also by the security setting |
| `set auto-load safe-path' (*note set auto-load safe-path::). |
| |
| This variable defaults to `$debugdir:$datadir/auto-load'. The |
| default `set auto-load safe-path' value can be also overriden by |
| GDB configuration option `--with-auto-load-dir'. |
| |
| Any reference to `$debugdir' will get replaced by |
| DEBUG-FILE-DIRECTORY value (*note Separate Debug Files::) and any |
| reference to `$datadir' will get replaced by DATA-DIRECTORY which |
| is determined at GDB startup (*note Data Files::). `$debugdir' and |
| `$datadir' must be placed as a directory component -- either alone |
| or delimited by `/' or `\' directory separators, depending on the |
| host platform. |
| |
| The list of directories uses path separator (`:' on GNU and Unix |
| systems, `;' on MS-Windows and MS-DOS) to separate directories, |
| similarly to the `PATH' environment variable. |
| |
| `show auto-load scripts-directory' |
| Show GDB auto-loaded scripts location. |
| |
| GDB does not track which files it has already auto-loaded this way. |
| GDB will load the associated script every time the corresponding |
| OBJFILE is opened. So your `-gdb.py' file should be careful to avoid |
| errors if it is evaluated more than once. |
| |
| |
| File: gdb.info, Node: dotdebug_gdb_scripts section, Next: Which flavor to choose?, Prev: objfile-gdb.py file, Up: Python Auto-loading |
| |
| 23.2.3.2 The `.debug_gdb_scripts' section |
| ......................................... |
| |
| For systems using file formats like ELF and COFF, when GDB loads a new |
| object file it will look for a special section named |
| `.debug_gdb_scripts'. If this section exists, its contents is a list |
| of names of scripts to load. |
| |
| GDB will look for each specified script file first in the current |
| directory and then along the source search path (*note Specifying |
| Source Directories: Source Path.), except that `$cdir' is not searched, |
| since the compilation directory is not relevant to scripts. |
| |
| Entries can be placed in section `.debug_gdb_scripts' with, for |
| example, this GCC macro: |
| |
| /* Note: The "MS" section flags are to remove duplicates. */ |
| #define DEFINE_GDB_SCRIPT(script_name) \ |
| asm("\ |
| .pushsection \".debug_gdb_scripts\", \"MS\",@progbits,1\n\ |
| .byte 1\n\ |
| .asciz \"" script_name "\"\n\ |
| .popsection \n\ |
| "); |
| |
| Then one can reference the macro in a header or source file like this: |
| |
| DEFINE_GDB_SCRIPT ("my-app-scripts.py") |
| |
| The script name may include directories if desired. |
| |
| Note that loading of this script file also requires accordingly |
| configured `auto-load safe-path' (*note Auto-loading safe path::). |
| |
| If the macro is put in a header, any application or library using |
| this header will get a reference to the specified script. |
| |
| |
| File: gdb.info, Node: Which flavor to choose?, Prev: dotdebug_gdb_scripts section, Up: Python Auto-loading |
| |
| 23.2.3.3 Which flavor to choose? |
| ................................ |
| |
| Given the multiple ways of auto-loading Python scripts, it might not |
| always be clear which one to choose. This section provides some |
| guidance. |
| |
| Benefits of the `-gdb.py' way: |
| |
| * Can be used with file formats that don't support multiple sections. |
| |
| * Ease of finding scripts for public libraries. |
| |
| Scripts specified in the `.debug_gdb_scripts' section are searched |
| for in the source search path. For publicly installed libraries, |
| e.g., `libstdc++', there typically isn't a source directory in |
| which to find the script. |
| |
| * Doesn't require source code additions. |
| |
| Benefits of the `.debug_gdb_scripts' way: |
| |
| * Works with static linking. |
| |
| Scripts for libraries done the `-gdb.py' way require an objfile to |
| trigger their loading. When an application is statically linked |
| the only objfile available is the executable, and it is cumbersome |
| to attach all the scripts from all the input libraries to the |
| executable's `-gdb.py' script. |
| |
| * Works with classes that are entirely inlined. |
| |
| Some classes can be entirely inlined, and thus there may not be an |
| associated shared library to attach a `-gdb.py' script to. |
| |
| * Scripts needn't be copied out of the source tree. |
| |
| In some circumstances, apps can be built out of large collections |
| of internal libraries, and the build infrastructure necessary to |
| install the `-gdb.py' scripts in a place where GDB can find them is |
| cumbersome. It may be easier to specify the scripts in the |
| `.debug_gdb_scripts' section as relative paths, and add a path to |
| the top of the source tree to the source search path. |
| |
| |
| File: gdb.info, Node: Python modules, Prev: Python Auto-loading, Up: Python |
| |
| 23.2.4 Python modules |
| --------------------- |
| |
| GDB comes with several modules to assist writing Python code. |
| |
| * Menu: |
| |
| * gdb.printing:: Building and registering pretty-printers. |
| * gdb.types:: Utilities for working with types. |
| * gdb.prompt:: Utilities for prompt value substitution. |
| |
| |
| File: gdb.info, Node: gdb.printing, Next: gdb.types, Up: Python modules |
| |
| 23.2.4.1 gdb.printing |
| ..................... |
| |
| This module provides a collection of utilities for working with |
| pretty-printers. |
| |
| `PrettyPrinter (NAME, SUBPRINTERS=None)' |
| This class specifies the API that makes `info pretty-printer', |
| `enable pretty-printer' and `disable pretty-printer' work. |
| Pretty-printers should generally inherit from this class. |
| |
| `SubPrettyPrinter (NAME)' |
| For printers that handle multiple types, this class specifies the |
| corresponding API for the subprinters. |
| |
| `RegexpCollectionPrettyPrinter (NAME)' |
| Utility class for handling multiple printers, all recognized via |
| regular expressions. *Note Writing a Pretty-Printer::, for an |
| example. |
| |
| `FlagEnumerationPrinter (NAME)' |
| A pretty-printer which handles printing of `enum' values. Unlike |
| GDB's built-in `enum' printing, this printer attempts to work |
| properly when there is some overlap between the enumeration |
| constants. NAME is the name of the printer and also the name of |
| the `enum' type to look up. |
| |
| `register_pretty_printer (OBJ, PRINTER, REPLACE=False)' |
| Register PRINTER with the pretty-printer list of OBJ. If REPLACE |
| is `True' then any existing copy of the printer is replaced. |
| Otherwise a `RuntimeError' exception is raised if a printer with |
| the same name already exists. |
| |
| |
| File: gdb.info, Node: gdb.types, Next: gdb.prompt, Prev: gdb.printing, Up: Python modules |
| |
| 23.2.4.2 gdb.types |
| .................. |
| |
| This module provides a collection of utilities for working with |
| `gdb.Type' objects. |
| |
| `get_basic_type (TYPE)' |
| Return TYPE with const and volatile qualifiers stripped, and with |
| typedefs and C++ references converted to the underlying type. |
| |
| C++ example: |
| |
| typedef const int const_int; |
| const_int foo (3); |
| const_int& foo_ref (foo); |
| int main () { return 0; } |
| |
| Then in gdb: |
| |
| (gdb) start |
| (gdb) python import gdb.types |
| (gdb) python foo_ref = gdb.parse_and_eval("foo_ref") |
| (gdb) python print gdb.types.get_basic_type(foo_ref.type) |
| int |
| |
| `has_field (TYPE, FIELD)' |
| Return `True' if TYPE, assumed to be a type with fields (e.g., a |
| structure or union), has field FIELD. |
| |
| `make_enum_dict (ENUM_TYPE)' |
| Return a Python `dictionary' type produced from ENUM_TYPE. |
| |
| `deep_items (TYPE)' |
| Returns a Python iterator similar to the standard |
| `gdb.Type.iteritems' method, except that the iterator returned by |
| `deep_items' will recursively traverse anonymous struct or union |
| fields. For example: |
| |
| struct A |
| { |
| int a; |
| union { |
| int b0; |
| int b1; |
| }; |
| }; |
| |
| Then in GDB: |
| (gdb) python import gdb.types |
| (gdb) python struct_a = gdb.lookup_type("struct A") |
| (gdb) python print struct_a.keys () |
| {['a', '']} |
| (gdb) python print [k for k,v in gdb.types.deep_items(struct_a)] |
| {['a', 'b0', 'b1']} |
| |
| `get_type_recognizers ()' |
| Return a list of the enabled type recognizers for the current |
| context. This is called by GDB during the type-printing process |
| (*note Type Printing API::). |
| |
| `apply_type_recognizers (recognizers, type_obj)' |
| Apply the type recognizers, RECOGNIZERS, to the type object |
| TYPE_OBJ. If any recognizer returns a string, return that string. |
| Otherwise, return `None'. This is called by GDB during the |
| type-printing process (*note Type Printing API::). |
| |
| `register_type_printer (locus, printer)' |
| This is a convenience function to register a type printer. |
| PRINTER is the type printer to register. It must implement the |
| type printer protocol. LOCUS is either a `gdb.Objfile', in which |
| case the printer is registered with that objfile; a |
| `gdb.Progspace', in which case the printer is registered with that |
| progspace; or `None', in which case the printer is registered |
| globally. |
| |
| `TypePrinter' |
| This is a base class that implements the type printer protocol. |
| Type printers are encouraged, but not required, to derive from |
| this class. It defines a constructor: |
| |
| -- Method on TypePrinter: __init__ (self, name) |
| Initialize the type printer with the given name. The new |
| printer starts in the enabled state. |
| |
| |
| |
| File: gdb.info, Node: gdb.prompt, Prev: gdb.types, Up: Python modules |
| |
| 23.2.4.3 gdb.prompt |
| ................... |
| |
| This module provides a method for prompt value-substitution. |
| |
| `substitute_prompt (STRING)' |
| Return STRING with escape sequences substituted by values. Some |
| escape sequences take arguments. You can specify arguments inside |
| "{}" immediately following the escape sequence. |
| |
| The escape sequences you can pass to this function are: |
| |
| `\\' |
| Substitute a backslash. |
| |
| `\e' |
| Substitute an ESC character. |
| |
| `\f' |
| Substitute the selected frame; an argument names a frame |
| parameter. |
| |
| `\n' |
| Substitute a newline. |
| |
| `\p' |
| Substitute a parameter's value; the argument names the |
| parameter. |
| |
| `\r' |
| Substitute a carriage return. |
| |
| `\t' |
| Substitute the selected thread; an argument names a thread |
| parameter. |
| |
| `\v' |
| Substitute the version of GDB. |
| |
| `\w' |
| Substitute the current working directory. |
| |
| `\[' |
| Begin a sequence of non-printing characters. These sequences |
| are typically used with the ESC character, and are not |
| counted in the string length. Example: |
| "\[\e[0;34m\](gdb)\[\e[0m\]" will return a blue-colored |
| "(gdb)" prompt where the length is five. |
| |
| `\]' |
| End a sequence of non-printing characters. |
| |
| For example: |
| |
| substitute_prompt (``frame: \f, |
| print arguments: \p{print frame-arguments}'') |
| |
| will return the string: |
| |
| |
| "frame: main, print arguments: scalars" |
| |
| |
| File: gdb.info, Node: Aliases, Prev: Python, Up: Extending GDB |
| |
| 23.3 Creating new spellings of existing commands |
| ================================================ |
| |
| It is often useful to define alternate spellings of existing commands. |
| For example, if a new GDB command defined in Python has a long name to |
| type, it is handy to have an abbreviated version of it that involves |
| less typing. |
| |
| GDB itself uses aliases. For example `s' is an alias of the `step' |
| command even though it is otherwise an ambiguous abbreviation of other |
| commands like `set' and `show'. |
| |
| Aliases are also used to provide shortened or more common versions |
| of multi-word commands. For example, GDB provides the `tty' alias of |
| the `set inferior-tty' command. |
| |
| You can define a new alias with the `alias' command. |
| |
| `alias [-a] [--] ALIAS = COMMAND' |
| |
| ALIAS specifies the name of the new alias. Each word of ALIAS must |
| consist of letters, numbers, dashes and underscores. |
| |
| COMMAND specifies the name of an existing command that is being |
| aliased. |
| |
| The `-a' option specifies that the new alias is an abbreviation of |
| the command. Abbreviations are not shown in command lists displayed by |
| the `help' command. |
| |
| The `--' option specifies the end of options, and is useful when |
| ALIAS begins with a dash. |
| |
| Here is a simple example showing how to make an abbreviation of a |
| command so that there is less to type. Suppose you were tired of |
| typing `disas', the current shortest unambiguous abbreviation of the |
| `disassemble' command and you wanted an even shorter version named `di'. |
| The following will accomplish this. |
| |
| (gdb) alias -a di = disas |
| |
| Note that aliases are different from user-defined commands. With a |
| user-defined command, you also need to write documentation for it with |
| the `document' command. An alias automatically picks up the |
| documentation of the existing command. |
| |
| Here is an example where we make `elms' an abbreviation of |
| `elements' in the `set print elements' command. This is to show that |
| you can make an abbreviation of any part of a command. |
| |
| (gdb) alias -a set print elms = set print elements |
| (gdb) alias -a show print elms = show print elements |
| (gdb) set p elms 20 |
| (gdb) show p elms |
| Limit on string chars or array elements to print is 200. |
| |
| Note that if you are defining an alias of a `set' command, and you |
| want to have an alias for the corresponding `show' command, then you |
| need to define the latter separately. |
| |
| Unambiguously abbreviated commands are allowed in COMMAND and ALIAS, |
| just as they are normally. |
| |
| (gdb) alias -a set pr elms = set p ele |
| |
| Finally, here is an example showing the creation of a one word alias |
| for a more complex command. This creates alias `spe' of the command |
| `set print elements'. |
| |
| (gdb) alias spe = set print elements |
| (gdb) spe 20 |
| |
| |
| File: gdb.info, Node: Interpreters, Next: TUI, Prev: Extending GDB, Up: Top |
| |
| 24 Command Interpreters |
| *********************** |
| |
| GDB supports multiple command interpreters, and some command |
| infrastructure to allow users or user interface writers to switch |
| between interpreters or run commands in other interpreters. |
| |
| GDB currently supports two command interpreters, the console |
| interpreter (sometimes called the command-line interpreter or CLI) and |
| the machine interface interpreter (or GDB/MI). This manual describes |
| both of these interfaces in great detail. |
| |
| By default, GDB will start with the console interpreter. However, |
| the user may choose to start GDB with another interpreter by specifying |
| the `-i' or `--interpreter' startup options. Defined interpreters |
| include: |
| |
| `console' |
| The traditional console or command-line interpreter. This is the |
| most often used interpreter with GDB. With no interpreter |
| specified at runtime, GDB will use this interpreter. |
| |
| `mi' |
| The newest GDB/MI interface (currently `mi2'). Used primarily by |
| programs wishing to use GDB as a backend for a debugger GUI or an |
| IDE. For more information, see *note The GDB/MI Interface: GDB/MI. |
| |
| `mi2' |
| The current GDB/MI interface. |
| |
| `mi1' |
| The GDB/MI interface included in GDB 5.1, 5.2, and 5.3. |
| |
| |
| The interpreter being used by GDB may not be dynamically switched at |
| runtime. Although possible, this could lead to a very precarious |
| situation. Consider an IDE using GDB/MI. If a user enters the command |
| "interpreter-set console" in a console view, GDB would switch to using |
| the console interpreter, rendering the IDE inoperable! |
| |
| Although you may only choose a single interpreter at startup, you |
| may execute commands in any interpreter from the current interpreter |
| using the appropriate command. If you are running the console |
| interpreter, simply use the `interpreter-exec' command: |
| |
| interpreter-exec mi "-data-list-register-names" |
| |
| GDB/MI has a similar command, although it is only available in |
| versions of GDB which support GDB/MI version 2 (or greater). |
| |
| |
| File: gdb.info, Node: TUI, Next: Emacs, Prev: Interpreters, Up: Top |
| |
| 25 GDB Text User Interface |
| ************************** |
| |
| * Menu: |
| |
| * TUI Overview:: TUI overview |
| * TUI Keys:: TUI key bindings |
| * TUI Single Key Mode:: TUI single key mode |
| * TUI Commands:: TUI-specific commands |
| * TUI Configuration:: TUI configuration variables |
| |
| The GDB Text User Interface (TUI) is a terminal interface which uses |
| the `curses' library to show the source file, the assembly output, the |
| program registers and GDB commands in separate text windows. The TUI |
| mode is supported only on platforms where a suitable version of the |
| `curses' library is available. |
| |
| The TUI mode is enabled by default when you invoke GDB as `gdb -tui'. |
| You can also switch in and out of TUI mode while GDB runs by using |
| various TUI commands and key bindings, such as `C-x C-a'. *Note TUI |
| Key Bindings: TUI Keys. |
| |
| |
| File: gdb.info, Node: TUI Overview, Next: TUI Keys, Up: TUI |
| |
| 25.1 TUI Overview |
| ================= |
| |
| In TUI mode, GDB can display several text windows: |
| |
| _command_ |
| This window is the GDB command window with the GDB prompt and the |
| GDB output. The GDB input is still managed using readline. |
| |
| _source_ |
| The source window shows the source file of the program. The |
| current line and active breakpoints are displayed in this window. |
| |
| _assembly_ |
| The assembly window shows the disassembly output of the program. |
| |
| _register_ |
| This window shows the processor registers. Registers are |
| highlighted when their values change. |
| |
| The source and assembly windows show the current program position by |
| highlighting the current line and marking it with a `>' marker. |
| Breakpoints are indicated with two markers. The first marker indicates |
| the breakpoint type: |
| |
| `B' |
| Breakpoint which was hit at least once. |
| |
| `b' |
| Breakpoint which was never hit. |
| |
| `H' |
| Hardware breakpoint which was hit at least once. |
| |
| `h' |
| Hardware breakpoint which was never hit. |
| |
| The second marker indicates whether the breakpoint is enabled or not: |
| |
| `+' |
| Breakpoint is enabled. |
| |
| `-' |
| Breakpoint is disabled. |
| |
| The source, assembly and register windows are updated when the |
| current thread changes, when the frame changes, or when the program |
| counter changes. |
| |
| These windows are not all visible at the same time. The command |
| window is always visible. The others can be arranged in several |
| layouts: |
| |
| * source only, |
| |
| * assembly only, |
| |
| * source and assembly, |
| |
| * source and registers, or |
| |
| * assembly and registers. |
| |
| A status line above the command window shows the following |
| information: |
| |
| _target_ |
| Indicates the current GDB target. (*note Specifying a Debugging |
| Target: Targets.). |
| |
| _process_ |
| Gives the current process or thread number. When no process is |
| being debugged, this field is set to `No process'. |
| |
| _function_ |
| Gives the current function name for the selected frame. The name |
| is demangled if demangling is turned on (*note Print Settings::). |
| When there is no symbol corresponding to the current program |
| counter, the string `??' is displayed. |
| |
| _line_ |
| Indicates the current line number for the selected frame. When |
| the current line number is not known, the string `??' is displayed. |
| |
| _pc_ |
| Indicates the current program counter address. |
| |
| |
| File: gdb.info, Node: TUI Keys, Next: TUI Single Key Mode, Prev: TUI Overview, Up: TUI |
| |
| 25.2 TUI Key Bindings |
| ===================== |
| |
| The TUI installs several key bindings in the readline keymaps (*note |
| Command Line Editing::). The following key bindings are installed for |
| both TUI mode and the GDB standard mode. |
| |
| `C-x C-a' |
| `C-x a' |
| `C-x A' |
| Enter or leave the TUI mode. When leaving the TUI mode, the |
| curses window management stops and GDB operates using its standard |
| mode, writing on the terminal directly. When reentering the TUI |
| mode, control is given back to the curses windows. The screen is |
| then refreshed. |
| |
| `C-x 1' |
| Use a TUI layout with only one window. The layout will either be |
| `source' or `assembly'. When the TUI mode is not active, it will |
| switch to the TUI mode. |
| |
| Think of this key binding as the Emacs `C-x 1' binding. |
| |
| `C-x 2' |
| Use a TUI layout with at least two windows. When the current |
| layout already has two windows, the next layout with two windows |
| is used. When a new layout is chosen, one window will always be |
| common to the previous layout and the new one. |
| |
| Think of it as the Emacs `C-x 2' binding. |
| |
| `C-x o' |
| Change the active window. The TUI associates several key bindings |
| (like scrolling and arrow keys) with the active window. This |
| command gives the focus to the next TUI window. |
| |
| Think of it as the Emacs `C-x o' binding. |
| |
| `C-x s' |
| Switch in and out of the TUI SingleKey mode that binds single keys |
| to GDB commands (*note TUI Single Key Mode::). |
| |
| The following key bindings only work in the TUI mode: |
| |
| <PgUp> |
| Scroll the active window one page up. |
| |
| <PgDn> |
| Scroll the active window one page down. |
| |
| <Up> |
| Scroll the active window one line up. |
| |
| <Down> |
| Scroll the active window one line down. |
| |
| <Left> |
| Scroll the active window one column left. |
| |
| <Right> |
| Scroll the active window one column right. |
| |
| `C-L' |
| Refresh the screen. |
| |
| Because the arrow keys scroll the active window in the TUI mode, they |
| are not available for their normal use by readline unless the command |
| window has the focus. When another window is active, you must use |
| other readline key bindings such as `C-p', `C-n', `C-b' and `C-f' to |
| control the command window. |
| |
| |
| File: gdb.info, Node: TUI Single Key Mode, Next: TUI Commands, Prev: TUI Keys, Up: TUI |
| |
| 25.3 TUI Single Key Mode |
| ======================== |
| |
| The TUI also provides a "SingleKey" mode, which binds several |
| frequently used GDB commands to single keys. Type `C-x s' to switch |
| into this mode, where the following key bindings are used: |
| |
| `c' |
| continue |
| |
| `d' |
| down |
| |
| `f' |
| finish |
| |
| `n' |
| next |
| |
| `q' |
| exit the SingleKey mode. |
| |
| `r' |
| run |
| |
| `s' |
| step |
| |
| `u' |
| up |
| |
| `v' |
| info locals |
| |
| `w' |
| where |
| |
| Other keys temporarily switch to the GDB command prompt. The key |
| that was pressed is inserted in the editing buffer so that it is |
| possible to type most GDB commands without interaction with the TUI |
| SingleKey mode. Once the command is entered the TUI SingleKey mode is |
| restored. The only way to permanently leave this mode is by typing `q' |
| or `C-x s'. |
| |
| |
| File: gdb.info, Node: TUI Commands, Next: TUI Configuration, Prev: TUI Single Key Mode, Up: TUI |
| |
| 25.4 TUI-specific Commands |
| ========================== |
| |
| The TUI has specific commands to control the text windows. These |
| commands are always available, even when GDB is not in the TUI mode. |
| When GDB is in the standard mode, most of these commands will |
| automatically switch to the TUI mode. |
| |
| Note that if GDB's `stdout' is not connected to a terminal, or GDB |
| has been started with the machine interface interpreter (*note The |
| GDB/MI Interface: GDB/MI.), most of these commands will fail with an |
| error, because it would not be possible or desirable to enable curses |
| window management. |
| |
| `info win' |
| List and give the size of all displayed windows. |
| |
| `layout next' |
| Display the next layout. |
| |
| `layout prev' |
| Display the previous layout. |
| |
| `layout src' |
| Display the source window only. |
| |
| `layout asm' |
| Display the assembly window only. |
| |
| `layout split' |
| Display the source and assembly window. |
| |
| `layout regs' |
| Display the register window together with the source or assembly |
| window. |
| |
| `focus next' |
| Make the next window active for scrolling. |
| |
| `focus prev' |
| Make the previous window active for scrolling. |
| |
| `focus src' |
| Make the source window active for scrolling. |
| |
| `focus asm' |
| Make the assembly window active for scrolling. |
| |
| `focus regs' |
| Make the register window active for scrolling. |
| |
| `focus cmd' |
| Make the command window active for scrolling. |
| |
| `refresh' |
| Refresh the screen. This is similar to typing `C-L'. |
| |
| `tui reg float' |
| Show the floating point registers in the register window. |
| |
| `tui reg general' |
| Show the general registers in the register window. |
| |
| `tui reg next' |
| Show the next register group. The list of register groups as well |
| as their order is target specific. The predefined register groups |
| are the following: `general', `float', `system', `vector', `all', |
| `save', `restore'. |
| |
| `tui reg system' |
| Show the system registers in the register window. |
| |
| `update' |
| Update the source window and the current execution point. |
| |
| `winheight NAME +COUNT' |
| `winheight NAME -COUNT' |
| Change the height of the window NAME by COUNT lines. Positive |
| counts increase the height, while negative counts decrease it. |
| |
| `tabset NCHARS' |
| Set the width of tab stops to be NCHARS characters. |
| |
| |
| File: gdb.info, Node: TUI Configuration, Prev: TUI Commands, Up: TUI |
| |
| 25.5 TUI Configuration Variables |
| ================================ |
| |
| Several configuration variables control the appearance of TUI windows. |
| |
| `set tui border-kind KIND' |
| Select the border appearance for the source, assembly and register |
| windows. The possible values are the following: |
| `space' |
| Use a space character to draw the border. |
| |
| `ascii' |
| Use ASCII characters `+', `-' and `|' to draw the border. |
| |
| `acs' |
| Use the Alternate Character Set to draw the border. The |
| border is drawn using character line graphics if the terminal |
| supports them. |
| |
| `set tui border-mode MODE' |
| `set tui active-border-mode MODE' |
| Select the display attributes for the borders of the inactive |
| windows or the active window. The MODE can be one of the |
| following: |
| `normal' |
| Use normal attributes to display the border. |
| |
| `standout' |
| Use standout mode. |
| |
| `reverse' |
| Use reverse video mode. |
| |
| `half' |
| Use half bright mode. |
| |
| `half-standout' |
| Use half bright and standout mode. |
| |
| `bold' |
| Use extra bright or bold mode. |
| |
| `bold-standout' |
| Use extra bright or bold and standout mode. |
| |
| |
| File: gdb.info, Node: Emacs, Next: GDB/MI, Prev: TUI, Up: Top |
| |
| 26 Using GDB under GNU Emacs |
| **************************** |
| |
| A special interface allows you to use GNU Emacs to view (and edit) the |
| source files for the program you are debugging with GDB. |
| |
| To use this interface, use the command `M-x gdb' in Emacs. Give the |
| executable file you want to debug as an argument. This command starts |
| GDB as a subprocess of Emacs, with input and output through a newly |
| created Emacs buffer. |
| |
| Running GDB under Emacs can be just like running GDB normally except |
| for two things: |
| |
| * All "terminal" input and output goes through an Emacs buffer, |
| called the GUD buffer. |
| |
| This applies both to GDB commands and their output, and to the |
| input and output done by the program you are debugging. |
| |
| This is useful because it means that you can copy the text of |
| previous commands and input them again; you can even use parts of |
| the output in this way. |
| |
| All the facilities of Emacs' Shell mode are available for |
| interacting with your program. In particular, you can send |
| signals the usual way--for example, `C-c C-c' for an interrupt, |
| `C-c C-z' for a stop. |
| |
| * GDB displays source code through Emacs. |
| |
| Each time GDB displays a stack frame, Emacs automatically finds the |
| source file for that frame and puts an arrow (`=>') at the left |
| margin of the current line. Emacs uses a separate buffer for |
| source display, and splits the screen to show both your GDB session |
| and the source. |
| |
| Explicit GDB `list' or search commands still produce output as |
| usual, but you probably have no reason to use them from Emacs. |
| |
| We call this "text command mode". Emacs 22.1, and later, also uses |
| a graphical mode, enabled by default, which provides further buffers |
| that can control the execution and describe the state of your program. |
| *Note GDB Graphical Interface: (Emacs)GDB Graphical Interface. |
| |
| If you specify an absolute file name when prompted for the `M-x gdb' |
| argument, then Emacs sets your current working directory to where your |
| program resides. If you only specify the file name, then Emacs sets |
| your current working directory to the directory associated with the |
| previous buffer. In this case, GDB may find your program by searching |
| your environment's `PATH' variable, but on some operating systems it |
| might not find the source. So, although the GDB input and output |
| session proceeds normally, the auxiliary buffer does not display the |
| current source and line of execution. |
| |
| The initial working directory of GDB is printed on the top line of |
| the GUD buffer and this serves as a default for the commands that |
| specify files for GDB to operate on. *Note Commands to Specify Files: |
| Files. |
| |
| By default, `M-x gdb' calls the program called `gdb'. If you need |
| to call GDB by a different name (for example, if you keep several |
| configurations around, with different names) you can customize the |
| Emacs variable `gud-gdb-command-name' to run the one you want. |
| |
| In the GUD buffer, you can use these special Emacs commands in |
| addition to the standard Shell mode commands: |
| |
| `C-h m' |
| Describe the features of Emacs' GUD Mode. |
| |
| `C-c C-s' |
| Execute to another source line, like the GDB `step' command; also |
| update the display window to show the current file and location. |
| |
| `C-c C-n' |
| Execute to next source line in this function, skipping all function |
| calls, like the GDB `next' command. Then update the display window |
| to show the current file and location. |
| |
| `C-c C-i' |
| Execute one instruction, like the GDB `stepi' command; update |
| display window accordingly. |
| |
| `C-c C-f' |
| Execute until exit from the selected stack frame, like the GDB |
| `finish' command. |
| |
| `C-c C-r' |
| Continue execution of your program, like the GDB `continue' |
| command. |
| |
| `C-c <' |
| Go up the number of frames indicated by the numeric argument |
| (*note Numeric Arguments: (Emacs)Arguments.), like the GDB `up' |
| command. |
| |
| `C-c >' |
| Go down the number of frames indicated by the numeric argument, |
| like the GDB `down' command. |
| |
| In any source file, the Emacs command `C-x <SPC>' (`gud-break') |
| tells GDB to set a breakpoint on the source line point is on. |
| |
| In text command mode, if you type `M-x speedbar', Emacs displays a |
| separate frame which shows a backtrace when the GUD buffer is current. |
| Move point to any frame in the stack and type <RET> to make it become |
| the current frame and display the associated source in the source |
| buffer. Alternatively, click `Mouse-2' to make the selected frame |
| become the current one. In graphical mode, the speedbar displays watch |
| expressions. |
| |
| If you accidentally delete the source-display buffer, an easy way to |
| get it back is to type the command `f' in the GDB buffer, to request a |
| frame display; when you run under Emacs, this recreates the source |
| buffer if necessary to show you the context of the current frame. |
| |
| The source files displayed in Emacs are in ordinary Emacs buffers |
| which are visiting the source files in the usual way. You can edit the |
| files with these buffers if you wish; but keep in mind that GDB |
| communicates with Emacs in terms of line numbers. If you add or delete |
| lines from the text, the line numbers that GDB knows cease to |
| correspond properly with the code. |
| |
| A more detailed description of Emacs' interaction with GDB is given |
| in the Emacs manual (*note Debuggers: (Emacs)Debuggers.). |
| |
| |
| File: gdb.info, Node: GDB/MI, Next: Annotations, Prev: Emacs, Up: Top |
| |
| 27 The GDB/MI Interface |
| *********************** |
| |
| Function and Purpose |
| ==================== |
| |
| GDB/MI is a line based machine oriented text interface to GDB and is |
| activated by specifying using the `--interpreter' command line option |
| (*note Mode Options::). It is specifically intended to support the |
| development of systems which use the debugger as just one small |
| component of a larger system. |
| |
| This chapter is a specification of the GDB/MI interface. It is |
| written in the form of a reference manual. |
| |
| Note that GDB/MI is still under construction, so some of the |
| features described below are incomplete and subject to change (*note |
| GDB/MI Development and Front Ends: GDB/MI Development and Front Ends.). |
| |
| Notation and Terminology |
| ======================== |
| |
| This chapter uses the following notation: |
| |
| * `|' separates two alternatives. |
| |
| * `[ SOMETHING ]' indicates that SOMETHING is optional: it may or |
| may not be given. |
| |
| * `( GROUP )*' means that GROUP inside the parentheses may repeat |
| zero or more times. |
| |
| * `( GROUP )+' means that GROUP inside the parentheses may repeat |
| one or more times. |
| |
| * `"STRING"' means a literal STRING. |
| |
| * Menu: |
| |
| * GDB/MI General Design:: |
| * GDB/MI Command Syntax:: |
| * GDB/MI Compatibility with CLI:: |
| * GDB/MI Development and Front Ends:: |
| * GDB/MI Output Records:: |
| * GDB/MI Simple Examples:: |
| * GDB/MI Command Description Format:: |
| * GDB/MI Breakpoint Commands:: |
| * GDB/MI Catchpoint Commands:: |
| * GDB/MI Program Context:: |
| * GDB/MI Thread Commands:: |
| * GDB/MI Ada Tasking Commands:: |
| * GDB/MI Program Execution:: |
| * GDB/MI Stack Manipulation:: |
| * GDB/MI Variable Objects:: |
| * GDB/MI Data Manipulation:: |
| * GDB/MI Tracepoint Commands:: |
| * GDB/MI Symbol Query:: |
| * GDB/MI File Commands:: |
| * GDB/MI Target Manipulation:: |
| * GDB/MI File Transfer Commands:: |
| * GDB/MI Ada Exceptions Commands:: |
| * GDB/MI Miscellaneous Commands:: |
| |
| |
| File: gdb.info, Node: GDB/MI General Design, Next: GDB/MI Command Syntax, Up: GDB/MI |
| |
| 27.1 GDB/MI General Design |
| ========================== |
| |
| Interaction of a GDB/MI frontend with GDB involves three |
| parts--commands sent to GDB, responses to those commands and |
| notifications. Each command results in exactly one response, |
| indicating either successful completion of the command, or an error. |
| For the commands that do not resume the target, the response contains |
| the requested information. For the commands that resume the target, the |
| response only indicates whether the target was successfully resumed. |
| Notifications is the mechanism for reporting changes in the state of the |
| target, or in GDB state, that cannot conveniently be associated with a |
| command and reported as part of that command response. |
| |
| The important examples of notifications are: |
| * Exec notifications. These are used to report changes in target |
| state--when a target is resumed, or stopped. It would not be |
| feasible to include this information in response of resuming |
| commands, because one resume commands can result in multiple |
| events in different threads. Also, quite some time may pass |
| before any event happens in the target, while a frontend needs to |
| know whether the resuming command itself was successfully executed. |
| |
| * Console output, and status notifications. Console output |
| notifications are used to report output of CLI commands, as well as |
| diagnostics for other commands. Status notifications are used to |
| report the progress of a long-running operation. Naturally, |
| including this information in command response would mean no |
| output is produced until the command is finished, which is |
| undesirable. |
| |
| * General notifications. Commands may have various side effects on |
| the GDB or target state beyond their official purpose. For |
| example, a command may change the selected thread. Although such |
| changes can be included in command response, using notification |
| allows for more orthogonal frontend design. |
| |
| |
| There's no guarantee that whenever an MI command reports an error, |
| GDB or the target are in any specific state, and especially, the state |
| is not reverted to the state before the MI command was processed. |
| Therefore, whenever an MI command results in an error, we recommend |
| that the frontend refreshes all the information shown in the user |
| interface. |
| |
| * Menu: |
| |
| * Context management:: |
| * Asynchronous and non-stop modes:: |
| * Thread groups:: |
| |
| |
| File: gdb.info, Node: Context management, Next: Asynchronous and non-stop modes, Up: GDB/MI General Design |
| |
| 27.1.1 Context management |
| ------------------------- |
| |
| 27.1.1.1 Threads and Frames |
| ........................... |
| |
| In most cases when GDB accesses the target, this access is done in |
| context of a specific thread and frame (*note Frames::). Often, even |
| when accessing global data, the target requires that a thread be |
| specified. The CLI interface maintains the selected thread and frame, |
| and supplies them to target on each command. This is convenient, |
| because a command line user would not want to specify that information |
| explicitly on each command, and because user interacts with GDB via a |
| single terminal, so no confusion is possible as to what thread and |
| frame are the current ones. |
| |
| In the case of MI, the concept of selected thread and frame is less |
| useful. First, a frontend can easily remember this information itself. |
| Second, a graphical frontend can have more than one window, each one |
| used for debugging a different thread, and the frontend might want to |
| access additional threads for internal purposes. This increases the |
| risk that by relying on implicitly selected thread, the frontend may be |
| operating on a wrong one. Therefore, each MI command should explicitly |
| specify which thread and frame to operate on. To make it possible, |
| each MI command accepts the `--thread' and `--frame' options, the value |
| to each is GDB identifier for thread and frame to operate on. |
| |
| Usually, each top-level window in a frontend allows the user to |
| select a thread and a frame, and remembers the user selection for |
| further operations. However, in some cases GDB may suggest that the |
| current thread be changed. For example, when stopping on a breakpoint |
| it is reasonable to switch to the thread where breakpoint is hit. For |
| another example, if the user issues the CLI `thread' command via the |
| frontend, it is desirable to change the frontend's selected thread to |
| the one specified by user. GDB communicates the suggestion to change |
| current thread using the `=thread-selected' notification. No such |
| notification is available for the selected frame at the moment. |
| |
| Note that historically, MI shares the selected thread with CLI, so |
| frontends used the `-thread-select' to execute commands in the right |
| context. However, getting this to work right is cumbersome. The |
| simplest way is for frontend to emit `-thread-select' command before |
| every command. This doubles the number of commands that need to be |
| sent. The alternative approach is to suppress `-thread-select' if the |
| selected thread in GDB is supposed to be identical to the thread the |
| frontend wants to operate on. However, getting this optimization right |
| can be tricky. In particular, if the frontend sends several commands |
| to GDB, and one of the commands changes the selected thread, then the |
| behaviour of subsequent commands will change. So, a frontend should |
| either wait for response from such problematic commands, or explicitly |
| add `-thread-select' for all subsequent commands. No frontend is known |
| to do this exactly right, so it is suggested to just always pass the |
| `--thread' and `--frame' options. |
| |
| 27.1.1.2 Language |
| ................. |
| |
| The execution of several commands depends on which language is selected. |
| By default, the current language (*note show language::) is used. But |
| for commands known to be language-sensitive, it is recommended to use |
| the `--language' option. This option takes one argument, which is the |
| name of the language to use while executing the command. For instance: |
| |
| -data-evaluate-expression --language c "sizeof (void*)" |
| ^done,value="4" |
| (gdb) |
| |
| The valid language names are the same names accepted by the `set |
| language' command (*note Manually::), excluding `auto', `local' or |
| `unknown'. |
| |
| |
| File: gdb.info, Node: Asynchronous and non-stop modes, Next: Thread groups, Prev: Context management, Up: GDB/MI General Design |
| |
| 27.1.2 Asynchronous command execution and non-stop mode |
| ------------------------------------------------------- |
| |
| On some targets, GDB is capable of processing MI commands even while |
| the target is running. This is called "asynchronous command execution" |
| (*note Background Execution::). The frontend may specify a preferrence |
| for asynchronous execution using the `-gdb-set target-async 1' command, |
| which should be emitted before either running the executable or |
| attaching to the target. After the frontend has started the executable |
| or attached to the target, it can find if asynchronous execution is |
| enabled using the `-list-target-features' command. |
| |
| Even if GDB can accept a command while target is running, many |
| commands that access the target do not work when the target is running. |
| Therefore, asynchronous command execution is most useful when combined |
| with non-stop mode (*note Non-Stop Mode::). Then, it is possible to |
| examine the state of one thread, while other threads are running. |
| |
| When a given thread is running, MI commands that try to access the |
| target in the context of that thread may not work, or may work only on |
| some targets. In particular, commands that try to operate on thread's |
| stack will not work, on any target. Commands that read memory, or |
| modify breakpoints, may work or not work, depending on the target. Note |
| that even commands that operate on global state, such as `print', |
| `set', and breakpoint commands, still access the target in the context |
| of a specific thread, so frontend should try to find a stopped thread |
| and perform the operation on that thread (using the `--thread' option). |
| |
| Which commands will work in the context of a running thread is |
| highly target dependent. However, the two commands `-exec-interrupt', |
| to stop a thread, and `-thread-info', to find the state of a thread, |
| will always work. |
| |
| |
| File: gdb.info, Node: Thread groups, Prev: Asynchronous and non-stop modes, Up: GDB/MI General Design |
| |
| 27.1.3 Thread groups |
| -------------------- |
| |
| GDB may be used to debug several processes at the same time. On some |
| platfroms, GDB may support debugging of several hardware systems, each |
| one having several cores with several different processes running on |
| each core. This section describes the MI mechanism to support such |
| debugging scenarios. |
| |
| The key observation is that regardless of the structure of the |
| target, MI can have a global list of threads, because most commands that |
| accept the `--thread' option do not need to know what process that |
| thread belongs to. Therefore, it is not necessary to introduce neither |
| additional `--process' option, nor an notion of the current process in |
| the MI interface. The only strictly new feature that is required is |
| the ability to find how the threads are grouped into processes. |
| |
| To allow the user to discover such grouping, and to support arbitrary |
| hierarchy of machines/cores/processes, MI introduces the concept of a |
| "thread group". Thread group is a collection of threads and other |
| thread groups. A thread group always has a string identifier, a type, |
| and may have additional attributes specific to the type. A new |
| command, `-list-thread-groups', returns the list of top-level thread |
| groups, which correspond to processes that GDB is debugging at the |
| moment. By passing an identifier of a thread group to the |
| `-list-thread-groups' command, it is possible to obtain the members of |
| specific thread group. |
| |
| To allow the user to easily discover processes, and other objects, he |
| wishes to debug, a concept of "available thread group" is introduced. |
| Available thread group is an thread group that GDB is not debugging, |
| but that can be attached to, using the `-target-attach' command. The |
| list of available top-level thread groups can be obtained using |
| `-list-thread-groups --available'. In general, the content of a thread |
| group may be only retrieved only after attaching to that thread group. |
| |
| Thread groups are related to inferiors (*note Inferiors and |
| Programs::). Each inferior corresponds to a thread group of a special |
| type `process', and some additional operations are permitted on such |
| thread groups. |
| |
| |
| File: gdb.info, Node: GDB/MI Command Syntax, Next: GDB/MI Compatibility with CLI, Prev: GDB/MI General Design, Up: GDB/MI |
| |
| 27.2 GDB/MI Command Syntax |
| ========================== |
| |
| * Menu: |
| |
| * GDB/MI Input Syntax:: |
| * GDB/MI Output Syntax:: |
| |
| |
| File: gdb.info, Node: GDB/MI Input Syntax, Next: GDB/MI Output Syntax, Up: GDB/MI Command Syntax |
| |
| 27.2.1 GDB/MI Input Syntax |
| -------------------------- |
| |
| `COMMAND ==>' |
| `CLI-COMMAND | MI-COMMAND' |
| |
| `CLI-COMMAND ==>' |
| `[ TOKEN ] CLI-COMMAND NL', where CLI-COMMAND is any existing GDB |
| CLI command. |
| |
| `MI-COMMAND ==>' |
| `[ TOKEN ] "-" OPERATION ( " " OPTION )* `[' " --" `]' ( " " |
| PARAMETER )* NL' |
| |
| `TOKEN ==>' |
| "any sequence of digits" |
| |
| `OPTION ==>' |
| `"-" PARAMETER [ " " PARAMETER ]' |
| |
| `PARAMETER ==>' |
| `NON-BLANK-SEQUENCE | C-STRING' |
| |
| `OPERATION ==>' |
| _any of the operations described in this chapter_ |
| |
| `NON-BLANK-SEQUENCE ==>' |
| _anything, provided it doesn't contain special characters such as |
| "-", NL, """ and of course " "_ |
| |
| `C-STRING ==>' |
| `""" SEVEN-BIT-ISO-C-STRING-CONTENT """' |
| |
| `NL ==>' |
| `CR | CR-LF' |
| |
| Notes: |
| |
| * The CLI commands are still handled by the MI interpreter; their |
| output is described below. |
| |
| * The `TOKEN', when present, is passed back when the command |
| finishes. |
| |
| * Some MI commands accept optional arguments as part of the parameter |
| list. Each option is identified by a leading `-' (dash) and may be |
| followed by an optional argument parameter. Options occur first |
| in the parameter list and can be delimited from normal parameters |
| using `--' (this is useful when some parameters begin with a dash). |
| |
| Pragmatics: |
| |
| * We want easy access to the existing CLI syntax (for debugging). |
| |
| * We want it to be easy to spot a MI operation. |
| |
| |
| File: gdb.info, Node: GDB/MI Output Syntax, Prev: GDB/MI Input Syntax, Up: GDB/MI Command Syntax |
| |
| 27.2.2 GDB/MI Output Syntax |
| --------------------------- |
| |
| The output from GDB/MI consists of zero or more out-of-band records |
| followed, optionally, by a single result record. This result record is |
| for the most recent command. The sequence of output records is |
| terminated by `(gdb)'. |
| |
| If an input command was prefixed with a `TOKEN' then the |
| corresponding output for that command will also be prefixed by that same |
| TOKEN. |
| |
| `OUTPUT ==>' |
| `( OUT-OF-BAND-RECORD )* [ RESULT-RECORD ] "(gdb)" NL' |
| |
| `RESULT-RECORD ==>' |
| ` [ TOKEN ] "^" RESULT-CLASS ( "," RESULT )* NL' |
| |
| `OUT-OF-BAND-RECORD ==>' |
| `ASYNC-RECORD | STREAM-RECORD' |
| |
| `ASYNC-RECORD ==>' |
| `EXEC-ASYNC-OUTPUT | STATUS-ASYNC-OUTPUT | NOTIFY-ASYNC-OUTPUT' |
| |
| `EXEC-ASYNC-OUTPUT ==>' |
| `[ TOKEN ] "*" ASYNC-OUTPUT' |
| |
| `STATUS-ASYNC-OUTPUT ==>' |
| `[ TOKEN ] "+" ASYNC-OUTPUT' |
| |
| `NOTIFY-ASYNC-OUTPUT ==>' |
| `[ TOKEN ] "=" ASYNC-OUTPUT' |
| |
| `ASYNC-OUTPUT ==>' |
| `ASYNC-CLASS ( "," RESULT )* NL' |
| |
| `RESULT-CLASS ==>' |
| `"done" | "running" | "connected" | "error" | "exit"' |
| |
| `ASYNC-CLASS ==>' |
| `"stopped" | OTHERS' (where OTHERS will be added depending on the |
| needs--this is still in development). |
| |
| `RESULT ==>' |
| ` VARIABLE "=" VALUE' |
| |
| `VARIABLE ==>' |
| ` STRING ' |
| |
| `VALUE ==>' |
| ` CONST | TUPLE | LIST ' |
| |
| `CONST ==>' |
| `C-STRING' |
| |
| `TUPLE ==>' |
| ` "{}" | "{" RESULT ( "," RESULT )* "}" ' |
| |
| `LIST ==>' |
| ` "[]" | "[" VALUE ( "," VALUE )* "]" | "[" RESULT ( "," RESULT )* |
| "]" ' |
| |
| `STREAM-RECORD ==>' |
| `CONSOLE-STREAM-OUTPUT | TARGET-STREAM-OUTPUT | LOG-STREAM-OUTPUT' |
| |
| `CONSOLE-STREAM-OUTPUT ==>' |
| `"~" C-STRING' |
| |
| `TARGET-STREAM-OUTPUT ==>' |
| `"@" C-STRING' |
| |
| `LOG-STREAM-OUTPUT ==>' |
| `"&" C-STRING' |
| |
| `NL ==>' |
| `CR | CR-LF' |
| |
| `TOKEN ==>' |
| _any sequence of digits_. |
| |
| Notes: |
| |
| * All output sequences end in a single line containing a period. |
| |
| * The `TOKEN' is from the corresponding request. Note that for all |
| async output, while the token is allowed by the grammar and may be |
| output by future versions of GDB for select async output messages, |
| it is generally omitted. Frontends should treat all async output |
| as reporting general changes in the state of the target and there |
| should be no need to associate async output to any prior command. |
| |
| * STATUS-ASYNC-OUTPUT contains on-going status information about the |
| progress of a slow operation. It can be discarded. All status |
| output is prefixed by `+'. |
| |
| * EXEC-ASYNC-OUTPUT contains asynchronous state change on the target |
| (stopped, started, disappeared). All async output is prefixed by |
| `*'. |
| |
| * NOTIFY-ASYNC-OUTPUT contains supplementary information that the |
| client should handle (e.g., a new breakpoint information). All |
| notify output is prefixed by `='. |
| |
| * CONSOLE-STREAM-OUTPUT is output that should be displayed as is in |
| the console. It is the textual response to a CLI command. All |
| the console output is prefixed by `~'. |
| |
| * TARGET-STREAM-OUTPUT is the output produced by the target program. |
| All the target output is prefixed by `@'. |
| |
| * LOG-STREAM-OUTPUT is output text coming from GDB's internals, for |
| instance messages that should be displayed as part of an error |
| log. All the log output is prefixed by `&'. |
| |
| * New GDB/MI commands should only output LISTS containing VALUES. |
| |
| |
| *Note GDB/MI Stream Records: GDB/MI Stream Records, for more details |
| about the various output records. |
| |
| |
| File: gdb.info, Node: GDB/MI Compatibility with CLI, Next: GDB/MI Development and Front Ends, Prev: GDB/MI Command Syntax, Up: GDB/MI |
| |
| 27.3 GDB/MI Compatibility with CLI |
| ================================== |
| |
| For the developers convenience CLI commands can be entered directly, |
| but there may be some unexpected behaviour. For example, commands that |
| query the user will behave as if the user replied yes, breakpoint |
| command lists are not executed and some CLI commands, such as `if', |
| `when' and `define', prompt for further input with `>', which is not |
| valid MI output. |
| |
| This feature may be removed at some stage in the future and it is |
| recommended that front ends use the `-interpreter-exec' command (*note |
| -interpreter-exec::). |
| |
| |
| File: gdb.info, Node: GDB/MI Development and Front Ends, Next: GDB/MI Output Records, Prev: GDB/MI Compatibility with CLI, Up: GDB/MI |
| |
| 27.4 GDB/MI Development and Front Ends |
| ====================================== |
| |
| The application which takes the MI output and presents the state of the |
| program being debugged to the user is called a "front end". |
| |
| Although GDB/MI is still incomplete, it is currently being used by a |
| variety of front ends to GDB. This makes it difficult to introduce new |
| functionality without breaking existing usage. This section tries to |
| minimize the problems by describing how the protocol might change. |
| |
| Some changes in MI need not break a carefully designed front end, and |
| for these the MI version will remain unchanged. The following is a |
| list of changes that may occur within one level, so front ends should |
| parse MI output in a way that can handle them: |
| |
| * New MI commands may be added. |
| |
| * New fields may be added to the output of any MI command. |
| |
| * The range of values for fields with specified values, e.g., |
| `in_scope' (*note -var-update::) may be extended. |
| |
| |
| If the changes are likely to break front ends, the MI version level |
| will be increased by one. This will allow the front end to parse the |
| output according to the MI version. Apart from mi0, new versions of |
| GDB will not support old versions of MI and it will be the |
| responsibility of the front end to work with the new one. |
| |
| The best way to avoid unexpected changes in MI that might break your |
| front end is to make your project known to GDB developers and follow |
| development on <gdb@sourceware.org> and <gdb-patches@sourceware.org>. |
| |
| |
| File: gdb.info, Node: GDB/MI Output Records, Next: GDB/MI Simple Examples, Prev: GDB/MI Development and Front Ends, Up: GDB/MI |
| |
| 27.5 GDB/MI Output Records |
| ========================== |
| |
| * Menu: |
| |
| * GDB/MI Result Records:: |
| * GDB/MI Stream Records:: |
| * GDB/MI Async Records:: |
| * GDB/MI Breakpoint Information:: |
| * GDB/MI Frame Information:: |
| * GDB/MI Thread Information:: |
| * GDB/MI Ada Exception Information:: |
| |
| |
| File: gdb.info, Node: GDB/MI Result Records, Next: GDB/MI Stream Records, Up: GDB/MI Output Records |
| |
| 27.5.1 GDB/MI Result Records |
| ---------------------------- |
| |
| In addition to a number of out-of-band notifications, the response to a |
| GDB/MI command includes one of the following result indications: |
| |
| `"^done" [ "," RESULTS ]' |
| The synchronous operation was successful, `RESULTS' are the return |
| values. |
| |
| `"^running"' |
| This result record is equivalent to `^done'. Historically, it was |
| output instead of `^done' if the command has resumed the target. |
| This behaviour is maintained for backward compatibility, but all |
| frontends should treat `^done' and `^running' identically and rely |
| on the `*running' output record to determine which threads are |
| resumed. |
| |
| `"^connected"' |
| GDB has connected to a remote target. |
| |
| `"^error" "," "msg=" C-STRING [ "," "code=" C-STRING ]' |
| The operation failed. The `msg=C-STRING' variable contains the |
| corresponding error message. |
| |
| If present, the `code=C-STRING' variable provides an error code on |
| which consumers can rely on to detect the corresponding error |
| condition. At present, only one error code is defined: |
| |
| `"undefined-command"' |
| Indicates that the command causing the error does not exist. |
| |
| `"^exit"' |
| GDB has terminated. |
| |
| |
| |
| File: gdb.info, Node: GDB/MI Stream Records, Next: GDB/MI Async Records, Prev: GDB/MI Result Records, Up: GDB/MI Output Records |
| |
| 27.5.2 GDB/MI Stream Records |
| ---------------------------- |
| |
| GDB internally maintains a number of output streams: the console, the |
| target, and the log. The output intended for each of these streams is |
| funneled through the GDB/MI interface using "stream records". |
| |
| Each stream record begins with a unique "prefix character" which |
| identifies its stream (*note GDB/MI Output Syntax: GDB/MI Output |
| Syntax.). In addition to the prefix, each stream record contains a |
| `STRING-OUTPUT'. This is either raw text (with an implicit new line) |
| or a quoted C string (which does not contain an implicit newline). |
| |
| `"~" STRING-OUTPUT' |
| The console output stream contains text that should be displayed |
| in the CLI console window. It contains the textual responses to |
| CLI commands. |
| |
| `"@" STRING-OUTPUT' |
| The target output stream contains any textual output from the |
| running target. This is only present when GDB's event loop is |
| truly asynchronous, which is currently only the case for remote |
| targets. |
| |
| `"&" STRING-OUTPUT' |
| The log stream contains debugging messages being produced by GDB's |
| internals. |
| |
| |
| File: gdb.info, Node: GDB/MI Async Records, Next: GDB/MI Breakpoint Information, Prev: GDB/MI Stream Records, Up: GDB/MI Output Records |
| |
| 27.5.3 GDB/MI Async Records |
| --------------------------- |
| |
| "Async" records are used to notify the GDB/MI client of additional |
| changes that have occurred. Those changes can either be a consequence |
| of GDB/MI commands (e.g., a breakpoint modified) or a result of target |
| activity (e.g., target stopped). |
| |
| The following is the list of possible async records: |
| |
| `*running,thread-id="THREAD"' |
| The target is now running. The THREAD field tells which specific |
| thread is now running, and can be `all' if all threads are |
| running. The frontend should assume that no interaction with a |
| running thread is possible after this notification is produced. |
| The frontend should not assume that this notification is output |
| only once for any command. GDB may emit this notification several |
| times, either for different threads, because it cannot resume all |
| threads together, or even for a single thread, if the thread must |
| be stepped though some code before letting it run freely. |
| |
| `*stopped,reason="REASON",thread-id="ID",stopped-threads="STOPPED",core="CORE"' |
| The target has stopped. The REASON field can have one of the |
| following values: |
| |
| `breakpoint-hit' |
| A breakpoint was reached. |
| |
| `watchpoint-trigger' |
| A watchpoint was triggered. |
| |
| `read-watchpoint-trigger' |
| A read watchpoint was triggered. |
| |
| `access-watchpoint-trigger' |
| An access watchpoint was triggered. |
| |
| `function-finished' |
| An -exec-finish or similar CLI command was accomplished. |
| |
| `location-reached' |
| An -exec-until or similar CLI command was accomplished. |
| |
| `watchpoint-scope' |
| A watchpoint has gone out of scope. |
| |
| `end-stepping-range' |
| An -exec-next, -exec-next-instruction, -exec-step, |
| -exec-step-instruction or similar CLI command was |
| accomplished. |
| |
| `exited-signalled' |
| The inferior exited because of a signal. |
| |
| `exited' |
| The inferior exited. |
| |
| `exited-normally' |
| The inferior exited normally. |
| |
| `signal-received' |
| A signal was received by the inferior. |
| |
| `solib-event' |
| The inferior has stopped due to a library being loaded or |
| unloaded. This can happen when `stop-on-solib-events' (*note |
| Files::) is set or when a `catch load' or `catch unload' |
| catchpoint is in use (*note Set Catchpoints::). |
| |
| `fork' |
| The inferior has forked. This is reported when `catch fork' |
| (*note Set Catchpoints::) has been used. |
| |
| `vfork' |
| The inferior has vforked. This is reported in when `catch |
| vfork' (*note Set Catchpoints::) has been used. |
| |
| `syscall-entry' |
| The inferior entered a system call. This is reported when |
| `catch syscall' (*note Set Catchpoints::) has been used. |
| |
| `syscall-entry' |
| The inferior returned from a system call. This is reported |
| when `catch syscall' (*note Set Catchpoints::) has been used. |
| |
| `exec' |
| The inferior called `exec'. This is reported when `catch |
| exec' (*note Set Catchpoints::) has been used. |
| |
| The ID field identifies the thread that directly caused the stop - |
| for example by hitting a breakpoint. Depending on whether all-stop |
| mode is in effect (*note All-Stop Mode::), GDB may either stop all |
| threads, or only the thread that directly triggered the stop. If |
| all threads are stopped, the STOPPED field will have the value of |
| `"all"'. Otherwise, the value of the STOPPED field will be a list |
| of thread identifiers. Presently, this list will always include a |
| single thread, but frontend should be prepared to see several |
| threads in the list. The CORE field reports the processor core on |
| which the stop event has happened. This field may be absent if |
| such information is not available. |
| |
| `=thread-group-added,id="ID"' |
| `=thread-group-removed,id="ID"' |
| A thread group was either added or removed. The ID field contains |
| the GDB identifier of the thread group. When a thread group is |
| added, it generally might not be associated with a running |
| process. When a thread group is removed, its id becomes invalid |
| and cannot be used in any way. |
| |
| `=thread-group-started,id="ID",pid="PID"' |
| A thread group became associated with a running program, either |
| because the program was just started or the thread group was |
| attached to a program. The ID field contains the GDB identifier |
| of the thread group. The PID field contains process identifier, |
| specific to the operating system. |
| |
| `=thread-group-exited,id="ID"[,exit-code="CODE"]' |
| A thread group is no longer associated with a running program, |
| either because the program has exited, or because it was detached |
| from. The ID field contains the GDB identifier of the thread |
| group. CODE is the exit code of the inferior; it exists only when |
| the inferior exited with some code. |
| |
| `=thread-created,id="ID",group-id="GID"' |
| `=thread-exited,id="ID",group-id="GID"' |
| A thread either was created, or has exited. The ID field contains |
| the GDB identifier of the thread. The GID field identifies the |
| thread group this thread belongs to. |
| |
| `=thread-selected,id="ID"' |
| Informs that the selected thread was changed as result of the last |
| command. This notification is not emitted as result of |
| `-thread-select' command but is emitted whenever an MI command |
| that is not documented to change the selected thread actually |
| changes it. In particular, invoking, directly or indirectly (via |
| user-defined command), the CLI `thread' command, will generate |
| this notification. |
| |
| We suggest that in response to this notification, front ends |
| highlight the selected thread and cause subsequent commands to |
| apply to that thread. |
| |
| `=library-loaded,...' |
| Reports that a new library file was loaded by the program. This |
| notification has 4 fields--ID, TARGET-NAME, HOST-NAME, and |
| SYMBOLS-LOADED. The ID field is an opaque identifier of the |
| library. For remote debugging case, TARGET-NAME and HOST-NAME |
| fields give the name of the library file on the target, and on the |
| host respectively. For native debugging, both those fields have |
| the same value. The SYMBOLS-LOADED field is emitted only for |
| backward compatibility and should not be relied on to convey any |
| useful information. The THREAD-GROUP field, if present, specifies |
| the id of the thread group in whose context the library was |
| loaded. If the field is absent, it means the library was loaded |
| in the context of all present thread groups. |
| |
| `=library-unloaded,...' |
| Reports that a library was unloaded by the program. This |
| notification has 3 fields--ID, TARGET-NAME and HOST-NAME with the |
| same meaning as for the `=library-loaded' notification. The |
| THREAD-GROUP field, if present, specifies the id of the thread |
| group in whose context the library was unloaded. If the field is |
| absent, it means the library was unloaded in the context of all |
| present thread groups. |
| |
| `=traceframe-changed,num=TFNUM,tracepoint=TPNUM' |
| `=traceframe-changed,end' |
| Reports that the trace frame was changed and its new number is |
| TFNUM. The number of the tracepoint associated with this trace |
| frame is TPNUM. |
| |
| `=tsv-created,name=NAME,initial=INITIAL' |
| Reports that the new trace state variable NAME is created with |
| initial value INITIAL. |
| |
| `=tsv-deleted,name=NAME' |
| `=tsv-deleted' |
| Reports that the trace state variable NAME is deleted or all trace |
| state variables are deleted. |
| |
| `=tsv-modified,name=NAME,initial=INITIAL[,current=CURRENT]' |
| Reports that the trace state variable NAME is modified with the |
| initial value INITIAL. The current value CURRENT of trace state |
| variable is optional and is reported if the current value of trace |
| state variable is known. |
| |
| `=breakpoint-created,bkpt={...}' |
| `=breakpoint-modified,bkpt={...}' |
| `=breakpoint-deleted,id=NUMBER' |
| Reports that a breakpoint was created, modified, or deleted, |
| respectively. Only user-visible breakpoints are reported to the MI |
| user. |
| |
| The BKPT argument is of the same form as returned by the various |
| breakpoint commands; *Note GDB/MI Breakpoint Commands::. The |
| NUMBER is the ordinal number of the breakpoint. |
| |
| Note that if a breakpoint is emitted in the result record of a |
| command, then it will not also be emitted in an async record. |
| |
| `=record-started,thread-group="ID"' |
| `=record-stopped,thread-group="ID"' |
| Execution log recording was either started or stopped on an |
| inferior. The ID is the GDB identifier of the thread group |
| corresponding to the affected inferior. |
| |
| `=cmd-param-changed,param=PARAM,value=VALUE' |
| Reports that a parameter of the command `set PARAM' is changed to |
| VALUE. In the multi-word `set' command, the PARAM is the whole |
| parameter list to `set' command. For example, In command `set |
| check type on', PARAM is `check type' and VALUE is `on'. |
| |
| `=memory-changed,thread-group=ID,addr=ADDR,len=LEN[,type="code"]' |
| Reports that bytes from ADDR to DATA + LEN were written in an |
| inferior. The ID is the identifier of the thread group |
| corresponding to the affected inferior. The optional |
| `type="code"' part is reported if the memory written to holds |
| executable code. |
| |
| |
| File: gdb.info, Node: GDB/MI Breakpoint Information, Next: GDB/MI Frame Information, Prev: GDB/MI Async Records, Up: GDB/MI Output Records |
| |
| 27.5.4 GDB/MI Breakpoint Information |
| ------------------------------------ |
| |
| When GDB reports information about a breakpoint, a tracepoint, a |
| watchpoint, or a catchpoint, it uses a tuple with the following fields: |
| |
| `number' |
| The breakpoint number. For a breakpoint that represents one |
| location of a multi-location breakpoint, this will be a dotted |
| pair, like `1.2'. |
| |
| `type' |
| The type of the breakpoint. For ordinary breakpoints this will be |
| `breakpoint', but many values are possible. |
| |
| `catch-type' |
| If the type of the breakpoint is `catchpoint', then this indicates |
| the exact type of catchpoint. |
| |
| `disp' |
| This is the breakpoint disposition--either `del', meaning that the |
| breakpoint will be deleted at the next stop, or `keep', meaning |
| that the breakpoint will not be deleted. |
| |
| `enabled' |
| This indicates whether the breakpoint is enabled, in which case the |
| value is `y', or disabled, in which case the value is `n'. Note |
| that this is not the same as the field `enable'. |
| |
| `addr' |
| The address of the breakpoint. This may be a hexidecimal number, |
| giving the address; or the string `<PENDING>', for a pending |
| breakpoint; or the string `<MULTIPLE>', for a breakpoint with |
| multiple locations. This field will not be present if no address |
| can be determined. For example, a watchpoint does not have an |
| address. |
| |
| `func' |
| If known, the function in which the breakpoint appears. If not |
| known, this field is not present. |
| |
| `filename' |
| The name of the source file which contains this function, if known. |
| If not known, this field is not present. |
| |
| `fullname' |
| The full file name of the source file which contains this |
| function, if known. If not known, this field is not present. |
| |
| `line' |
| The line number at which this breakpoint appears, if known. If |
| not known, this field is not present. |
| |
| `at' |
| If the source file is not known, this field may be provided. If |
| provided, this holds the address of the breakpoint, possibly |
| followed by a symbol name. |
| |
| `pending' |
| If this breakpoint is pending, this field is present and holds the |
| text used to set the breakpoint, as entered by the user. |
| |
| `evaluated-by' |
| Where this breakpoint's condition is evaluated, either `host' or |
| `target'. |
| |
| `thread' |
| If this is a thread-specific breakpoint, then this identifies the |
| thread in which the breakpoint can trigger. |
| |
| `task' |
| If this breakpoint is restricted to a particular Ada task, then |
| this field will hold the task identifier. |
| |
| `cond' |
| If the breakpoint is conditional, this is the condition expression. |
| |
| `ignore' |
| The ignore count of the breakpoint. |
| |
| `enable' |
| The enable count of the breakpoint. |
| |
| `traceframe-usage' |
| FIXME. |
| |
| `static-tracepoint-marker-string-id' |
| For a static tracepoint, the name of the static tracepoint marker. |
| |
| `mask' |
| For a masked watchpoint, this is the mask. |
| |
| `pass' |
| A tracepoint's pass count. |
| |
| `original-location' |
| The location of the breakpoint as originally specified by the user. |
| This field is optional. |
| |
| `times' |
| The number of times the breakpoint has been hit. |
| |
| `installed' |
| This field is only given for tracepoints. This is either `y', |
| meaning that the tracepoint is installed, or `n', meaning that it |
| is not. |
| |
| `what' |
| Some extra data, the exact contents of which are type-dependent. |
| |
| |
| For example, here is what the output of `-break-insert' (*note |
| GDB/MI Breakpoint Commands::) might be: |
| |
| -> -break-insert main |
| <- ^done,bkpt={number="1",type="breakpoint",disp="keep", |
| enabled="y",addr="0x08048564",func="main",file="myprog.c", |
| fullname="/home/nickrob/myprog.c",line="68",thread-groups=["i1"], |
| times="0"} |
| <- (gdb) |
| |
| |
| File: gdb.info, Node: GDB/MI Frame Information, Next: GDB/MI Thread Information, Prev: GDB/MI Breakpoint Information, Up: GDB/MI Output Records |
| |
| 27.5.5 GDB/MI Frame Information |
| ------------------------------- |
| |
| Response from many MI commands includes an information about stack |
| frame. This information is a tuple that may have the following fields: |
| |
| `level' |
| The level of the stack frame. The innermost frame has the level of |
| zero. This field is always present. |
| |
| `func' |
| The name of the function corresponding to the frame. This field |
| may be absent if GDB is unable to determine the function name. |
| |
| `addr' |
| The code address for the frame. This field is always present. |
| |
| `file' |
| The name of the source files that correspond to the frame's code |
| address. This field may be absent. |
| |
| `line' |
| The source line corresponding to the frames' code address. This |
| field may be absent. |
| |
| `from' |
| The name of the binary file (either executable or shared library) |
| the corresponds to the frame's code address. This field may be |
| absent. |
| |
| |
| |
| File: gdb.info, Node: GDB/MI Thread Information, Next: GDB/MI Ada Exception Information, Prev: GDB/MI Frame Information, Up: GDB/MI Output Records |
| |
| 27.5.6 GDB/MI Thread Information |
| -------------------------------- |
| |
| Whenever GDB has to report an information about a thread, it uses a |
| tuple with the following fields: |
| |
| `id' |
| The numeric id assigned to the thread by GDB. This field is |
| always present. |
| |
| `target-id' |
| Target-specific string identifying the thread. This field is |
| always present. |
| |
| `details' |
| Additional information about the thread provided by the target. |
| It is supposed to be human-readable and not interpreted by the |
| frontend. This field is optional. |
| |
| `state' |
| Either `stopped' or `running', depending on whether the thread is |
| presently running. This field is always present. |
| |
| `core' |
| The value of this field is an integer number of the processor core |
| the thread was last seen on. This field is optional. |
| |
| |
| File: gdb.info, Node: GDB/MI Ada Exception Information, Prev: GDB/MI Thread Information, Up: GDB/MI Output Records |
| |
| 27.5.7 GDB/MI Ada Exception Information |
| --------------------------------------- |
| |
| Whenever a `*stopped' record is emitted because the program stopped |
| after hitting an exception catchpoint (*note Set Catchpoints::), GDB |
| provides the name of the exception that was raised via the |
| `exception-name' field. |
| |
| |
| File: gdb.info, Node: GDB/MI Simple Examples, Next: GDB/MI Command Description Format, Prev: GDB/MI Output Records, Up: GDB/MI |
| |
| 27.6 Simple Examples of GDB/MI Interaction |
| ========================================== |
| |
| This subsection presents several simple examples of interaction using |
| the GDB/MI interface. In these examples, `->' means that the following |
| line is passed to GDB/MI as input, while `<-' means the output received |
| from GDB/MI. |
| |
| Note the line breaks shown in the examples are here only for |
| readability, they don't appear in the real output. |
| |
| Setting a Breakpoint |
| -------------------- |
| |
| Setting a breakpoint generates synchronous output which contains |
| detailed information of the breakpoint. |
| |
| -> -break-insert main |
| <- ^done,bkpt={number="1",type="breakpoint",disp="keep", |
| enabled="y",addr="0x08048564",func="main",file="myprog.c", |
| fullname="/home/nickrob/myprog.c",line="68",thread-groups=["i1"], |
| times="0"} |
| <- (gdb) |
| |
| Program Execution |
| ----------------- |
| |
| Program execution generates asynchronous records and MI gives the |
| reason that execution stopped. |
| |
| -> -exec-run |
| <- ^running |
| <- (gdb) |
| <- *stopped,reason="breakpoint-hit",disp="keep",bkptno="1",thread-id="0", |
| frame={addr="0x08048564",func="main", |
| args=[{name="argc",value="1"},{name="argv",value="0xbfc4d4d4"}], |
| file="myprog.c",fullname="/home/nickrob/myprog.c",line="68"} |
| <- (gdb) |
| -> -exec-continue |
| <- ^running |
| <- (gdb) |
| <- *stopped,reason="exited-normally" |
| <- (gdb) |
| |
| Quitting GDB |
| ------------ |
| |
| Quitting GDB just prints the result class `^exit'. |
| |
| -> (gdb) |
| <- -gdb-exit |
| <- ^exit |
| |
| Please note that `^exit' is printed immediately, but it might take |
| some time for GDB to actually exit. During that time, GDB performs |
| necessary cleanups, including killing programs being debugged or |
| disconnecting from debug hardware, so the frontend should wait till GDB |
| exits and should only forcibly kill GDB if it fails to exit in |
| reasonable time. |
| |
| A Bad Command |
| ------------- |
| |
| Here's what happens if you pass a non-existent command: |
| |
| -> -rubbish |
| <- ^error,msg="Undefined MI command: rubbish" |
| <- (gdb) |
| |
| |
| File: gdb.info, Node: GDB/MI Command Description Format, Next: GDB/MI Breakpoint Commands, Prev: GDB/MI Simple Examples, Up: GDB/MI |
| |
| 27.7 GDB/MI Command Description Format |
| ====================================== |
| |
| The remaining sections describe blocks of commands. Each block of |
| commands is laid out in a fashion similar to this section. |
| |
| Motivation |
| ---------- |
| |
| The motivation for this collection of commands. |
| |
| Introduction |
| ------------ |
| |
| A brief introduction to this collection of commands as a whole. |
| |
| Commands |
| -------- |
| |
| For each command in the block, the following is described: |
| |
| Synopsis |
| ........ |
| |
| -command ARGS... |
| |
| Result |
| ...... |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB CLI command(s), if any. |
| |
| Example |
| ....... |
| |
| Example(s) formatted for readability. Some of the described commands |
| have not been implemented yet and these are labeled N.A. (not |
| available). |
| |
| |
| File: gdb.info, Node: GDB/MI Breakpoint Commands, Next: GDB/MI Catchpoint Commands, Prev: GDB/MI Command Description Format, Up: GDB/MI |
| |
| 27.8 GDB/MI Breakpoint Commands |
| =============================== |
| |
| This section documents GDB/MI commands for manipulating breakpoints. |
| |
| The `-break-after' Command |
| -------------------------- |
| |
| Synopsis |
| ........ |
| |
| -break-after NUMBER COUNT |
| |
| The breakpoint number NUMBER is not in effect until it has been hit |
| COUNT times. To see how this is reflected in the output of the |
| `-break-list' command, see the description of the `-break-list' command |
| below. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `ignore'. |
| |
| Example |
| ....... |
| |
| (gdb) |
| -break-insert main |
| ^done,bkpt={number="1",type="breakpoint",disp="keep", |
| enabled="y",addr="0x000100d0",func="main",file="hello.c", |
| fullname="/home/foo/hello.c",line="5",thread-groups=["i1"], |
| times="0"} |
| (gdb) |
| -break-after 1 3 |
| ~ |
| ^done |
| (gdb) |
| -break-list |
| ^done,BreakpointTable={nr_rows="1",nr_cols="6", |
| hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"}, |
| {width="14",alignment="-1",col_name="type",colhdr="Type"}, |
| {width="4",alignment="-1",col_name="disp",colhdr="Disp"}, |
| {width="3",alignment="-1",col_name="enabled",colhdr="Enb"}, |
| {width="10",alignment="-1",col_name="addr",colhdr="Address"}, |
| {width="40",alignment="2",col_name="what",colhdr="What"}], |
| body=[bkpt={number="1",type="breakpoint",disp="keep",enabled="y", |
| addr="0x000100d0",func="main",file="hello.c",fullname="/home/foo/hello.c", |
| line="5",thread-groups=["i1"],times="0",ignore="3"}]} |
| (gdb) |
| |
| The `-break-commands' Command |
| ----------------------------- |
| |
| Synopsis |
| ........ |
| |
| -break-commands NUMBER [ COMMAND1 ... COMMANDN ] |
| |
| Specifies the CLI commands that should be executed when breakpoint |
| NUMBER is hit. The parameters COMMAND1 to COMMANDN are the commands. |
| If no command is specified, any previously-set commands are cleared. |
| *Note Break Commands::. Typical use of this functionality is tracing a |
| program, that is, printing of values of some variables whenever |
| breakpoint is hit and then continuing. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `commands'. |
| |
| Example |
| ....... |
| |
| (gdb) |
| -break-insert main |
| ^done,bkpt={number="1",type="breakpoint",disp="keep", |
| enabled="y",addr="0x000100d0",func="main",file="hello.c", |
| fullname="/home/foo/hello.c",line="5",thread-groups=["i1"], |
| times="0"} |
| (gdb) |
| -break-commands 1 "print v" "continue" |
| ^done |
| (gdb) |
| |
| The `-break-condition' Command |
| ------------------------------ |
| |
| Synopsis |
| ........ |
| |
| -break-condition NUMBER EXPR |
| |
| Breakpoint NUMBER will stop the program only if the condition in |
| EXPR is true. The condition becomes part of the `-break-list' output |
| (see the description of the `-break-list' command below). |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `condition'. |
| |
| Example |
| ....... |
| |
| (gdb) |
| -break-condition 1 1 |
| ^done |
| (gdb) |
| -break-list |
| ^done,BreakpointTable={nr_rows="1",nr_cols="6", |
| hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"}, |
| {width="14",alignment="-1",col_name="type",colhdr="Type"}, |
| {width="4",alignment="-1",col_name="disp",colhdr="Disp"}, |
| {width="3",alignment="-1",col_name="enabled",colhdr="Enb"}, |
| {width="10",alignment="-1",col_name="addr",colhdr="Address"}, |
| {width="40",alignment="2",col_name="what",colhdr="What"}], |
| body=[bkpt={number="1",type="breakpoint",disp="keep",enabled="y", |
| addr="0x000100d0",func="main",file="hello.c",fullname="/home/foo/hello.c", |
| line="5",cond="1",thread-groups=["i1"],times="0",ignore="3"}]} |
| (gdb) |
| |
| The `-break-delete' Command |
| --------------------------- |
| |
| Synopsis |
| ........ |
| |
| -break-delete ( BREAKPOINT )+ |
| |
| Delete the breakpoint(s) whose number(s) are specified in the |
| argument list. This is obviously reflected in the breakpoint list. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `delete'. |
| |
| Example |
| ....... |
| |
| (gdb) |
| -break-delete 1 |
| ^done |
| (gdb) |
| -break-list |
| ^done,BreakpointTable={nr_rows="0",nr_cols="6", |
| hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"}, |
| {width="14",alignment="-1",col_name="type",colhdr="Type"}, |
| {width="4",alignment="-1",col_name="disp",colhdr="Disp"}, |
| {width="3",alignment="-1",col_name="enabled",colhdr="Enb"}, |
| {width="10",alignment="-1",col_name="addr",colhdr="Address"}, |
| {width="40",alignment="2",col_name="what",colhdr="What"}], |
| body=[]} |
| (gdb) |
| |
| The `-break-disable' Command |
| ---------------------------- |
| |
| Synopsis |
| ........ |
| |
| -break-disable ( BREAKPOINT )+ |
| |
| Disable the named BREAKPOINT(s). The field `enabled' in the break |
| list is now set to `n' for the named BREAKPOINT(s). |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `disable'. |
| |
| Example |
| ....... |
| |
| (gdb) |
| -break-disable 2 |
| ^done |
| (gdb) |
| -break-list |
| ^done,BreakpointTable={nr_rows="1",nr_cols="6", |
| hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"}, |
| {width="14",alignment="-1",col_name="type",colhdr="Type"}, |
| {width="4",alignment="-1",col_name="disp",colhdr="Disp"}, |
| {width="3",alignment="-1",col_name="enabled",colhdr="Enb"}, |
| {width="10",alignment="-1",col_name="addr",colhdr="Address"}, |
| {width="40",alignment="2",col_name="what",colhdr="What"}], |
| body=[bkpt={number="2",type="breakpoint",disp="keep",enabled="n", |
| addr="0x000100d0",func="main",file="hello.c",fullname="/home/foo/hello.c", |
| line="5",thread-groups=["i1"],times="0"}]} |
| (gdb) |
| |
| The `-break-enable' Command |
| --------------------------- |
| |
| Synopsis |
| ........ |
| |
| -break-enable ( BREAKPOINT )+ |
| |
| Enable (previously disabled) BREAKPOINT(s). |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `enable'. |
| |
| Example |
| ....... |
| |
| (gdb) |
| -break-enable 2 |
| ^done |
| (gdb) |
| -break-list |
| ^done,BreakpointTable={nr_rows="1",nr_cols="6", |
| hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"}, |
| {width="14",alignment="-1",col_name="type",colhdr="Type"}, |
| {width="4",alignment="-1",col_name="disp",colhdr="Disp"}, |
| {width="3",alignment="-1",col_name="enabled",colhdr="Enb"}, |
| {width="10",alignment="-1",col_name="addr",colhdr="Address"}, |
| {width="40",alignment="2",col_name="what",colhdr="What"}], |
| body=[bkpt={number="2",type="breakpoint",disp="keep",enabled="y", |
| addr="0x000100d0",func="main",file="hello.c",fullname="/home/foo/hello.c", |
| line="5",thread-groups=["i1"],times="0"}]} |
| (gdb) |
| |
| The `-break-info' Command |
| ------------------------- |
| |
| Synopsis |
| ........ |
| |
| -break-info BREAKPOINT |
| |
| Get information about a single breakpoint. |
| |
| The result is a table of breakpoints. *Note GDB/MI Breakpoint |
| Information::, for details on the format of each breakpoint in the |
| table. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `info break BREAKPOINT'. |
| |
| Example |
| ....... |
| |
| N.A. |
| |
| The `-break-insert' Command |
| --------------------------- |
| |
| Synopsis |
| ........ |
| |
| -break-insert [ -t ] [ -h ] [ -f ] [ -d ] [ -a ] |
| [ -c CONDITION ] [ -i IGNORE-COUNT ] |
| [ -p THREAD-ID ] [ LOCATION ] |
| |
| If specified, LOCATION, can be one of: |
| |
| * function |
| |
| * filename:linenum |
| |
| * filename:function |
| |
| * *address |
| |
| The possible optional parameters of this command are: |
| |
| `-t' |
| Insert a temporary breakpoint. |
| |
| `-h' |
| Insert a hardware breakpoint. |
| |
| `-f' |
| If LOCATION cannot be parsed (for example if it refers to unknown |
| files or functions), create a pending breakpoint. Without this |
| flag, GDB will report an error, and won't create a breakpoint, if |
| LOCATION cannot be parsed. |
| |
| `-d' |
| Create a disabled breakpoint. |
| |
| `-a' |
| Create a tracepoint. *Note Tracepoints::. When this parameter is |
| used together with `-h', a fast tracepoint is created. |
| |
| `-c CONDITION' |
| Make the breakpoint conditional on CONDITION. |
| |
| `-i IGNORE-COUNT' |
| Initialize the IGNORE-COUNT. |
| |
| `-p THREAD-ID' |
| Restrict the breakpoint to the specified THREAD-ID. |
| |
| Result |
| ...... |
| |
| *Note GDB/MI Breakpoint Information::, for details on the format of the |
| resulting breakpoint. |
| |
| Note: this format is open to change. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB commands are `break', `tbreak', `hbreak', and |
| `thbreak'. |
| |
| Example |
| ....... |
| |
| (gdb) |
| -break-insert main |
| ^done,bkpt={number="1",addr="0x0001072c",file="recursive2.c", |
| fullname="/home/foo/recursive2.c,line="4",thread-groups=["i1"], |
| times="0"} |
| (gdb) |
| -break-insert -t foo |
| ^done,bkpt={number="2",addr="0x00010774",file="recursive2.c", |
| fullname="/home/foo/recursive2.c,line="11",thread-groups=["i1"], |
| times="0"} |
| (gdb) |
| -break-list |
| ^done,BreakpointTable={nr_rows="2",nr_cols="6", |
| hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"}, |
| {width="14",alignment="-1",col_name="type",colhdr="Type"}, |
| {width="4",alignment="-1",col_name="disp",colhdr="Disp"}, |
| {width="3",alignment="-1",col_name="enabled",colhdr="Enb"}, |
| {width="10",alignment="-1",col_name="addr",colhdr="Address"}, |
| {width="40",alignment="2",col_name="what",colhdr="What"}], |
| body=[bkpt={number="1",type="breakpoint",disp="keep",enabled="y", |
| addr="0x0001072c", func="main",file="recursive2.c", |
| fullname="/home/foo/recursive2.c,"line="4",thread-groups=["i1"], |
| times="0"}, |
| bkpt={number="2",type="breakpoint",disp="del",enabled="y", |
| addr="0x00010774",func="foo",file="recursive2.c", |
| fullname="/home/foo/recursive2.c",line="11",thread-groups=["i1"], |
| times="0"}]} |
| (gdb) |
| |
| The `-dprintf-insert' Command |
| ----------------------------- |
| |
| Synopsis |
| ........ |
| |
| -dprintf-insert [ -t ] [ -f ] [ -d ] |
| [ -c CONDITION ] [ -i IGNORE-COUNT ] |
| [ -p THREAD-ID ] [ LOCATION ] [ FORMAT ] |
| [ ARGUMENT ] |
| |
| If specified, LOCATION, can be one of: |
| |
| * FUNCTION |
| |
| * FILENAME:LINENUM |
| |
| * FILENAME:function |
| |
| * *ADDRESS |
| |
| The possible optional parameters of this command are: |
| |
| `-t' |
| Insert a temporary breakpoint. |
| |
| `-f' |
| If LOCATION cannot be parsed (for example, if it refers to unknown |
| files or functions), create a pending breakpoint. Without this |
| flag, GDB will report an error, and won't create a breakpoint, if |
| LOCATION cannot be parsed. |
| |
| `-d' |
| Create a disabled breakpoint. |
| |
| `-c CONDITION' |
| Make the breakpoint conditional on CONDITION. |
| |
| `-i IGNORE-COUNT' |
| Set the ignore count of the breakpoint (*note ignore count: |
| Conditions.) to IGNORE-COUNT. |
| |
| `-p THREAD-ID' |
| Restrict the breakpoint to the specified THREAD-ID. |
| |
| Result |
| ...... |
| |
| *Note GDB/MI Breakpoint Information::, for details on the format of the |
| resulting breakpoint. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `dprintf'. |
| |
| Example |
| ....... |
| |
| (gdb) |
| 4-dprintf-insert foo "At foo entry\n" |
| 4^done,bkpt={number="1",type="dprintf",disp="keep",enabled="y", |
| addr="0x000000000040061b",func="foo",file="mi-dprintf.c", |
| fullname="mi-dprintf.c",line="25",thread-groups=["i1"], |
| times="0",script={"printf \"At foo entry\\n\"","continue"}, |
| original-location="foo"} |
| (gdb) |
| 5-dprintf-insert 26 "arg=%d, g=%d\n" arg g |
| 5^done,bkpt={number="2",type="dprintf",disp="keep",enabled="y", |
| addr="0x000000000040062a",func="foo",file="mi-dprintf.c", |
| fullname="mi-dprintf.c",line="26",thread-groups=["i1"], |
| times="0",script={"printf \"arg=%d, g=%d\\n\", arg, g","continue"}, |
| original-location="mi-dprintf.c:26"} |
| (gdb) |
| |
| The `-break-list' Command |
| ------------------------- |
| |
| Synopsis |
| ........ |
| |
| -break-list |
| |
| Displays the list of inserted breakpoints, showing the following |
| fields: |
| |
| `Number' |
| number of the breakpoint |
| |
| `Type' |
| type of the breakpoint: `breakpoint' or `watchpoint' |
| |
| `Disposition' |
| should the breakpoint be deleted or disabled when it is hit: `keep' |
| or `nokeep' |
| |
| `Enabled' |
| is the breakpoint enabled or no: `y' or `n' |
| |
| `Address' |
| memory location at which the breakpoint is set |
| |
| `What' |
| logical location of the breakpoint, expressed by function name, |
| file name, line number |
| |
| `Thread-groups' |
| list of thread groups to which this breakpoint applies |
| |
| `Times' |
| number of times the breakpoint has been hit |
| |
| If there are no breakpoints or watchpoints, the `BreakpointTable' |
| `body' field is an empty list. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `info break'. |
| |
| Example |
| ....... |
| |
| (gdb) |
| -break-list |
| ^done,BreakpointTable={nr_rows="2",nr_cols="6", |
| hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"}, |
| {width="14",alignment="-1",col_name="type",colhdr="Type"}, |
| {width="4",alignment="-1",col_name="disp",colhdr="Disp"}, |
| {width="3",alignment="-1",col_name="enabled",colhdr="Enb"}, |
| {width="10",alignment="-1",col_name="addr",colhdr="Address"}, |
| {width="40",alignment="2",col_name="what",colhdr="What"}], |
| body=[bkpt={number="1",type="breakpoint",disp="keep",enabled="y", |
| addr="0x000100d0",func="main",file="hello.c",line="5",thread-groups=["i1"], |
| times="0"}, |
| bkpt={number="2",type="breakpoint",disp="keep",enabled="y", |
| addr="0x00010114",func="foo",file="hello.c",fullname="/home/foo/hello.c", |
| line="13",thread-groups=["i1"],times="0"}]} |
| (gdb) |
| |
| Here's an example of the result when there are no breakpoints: |
| |
| (gdb) |
| -break-list |
| ^done,BreakpointTable={nr_rows="0",nr_cols="6", |
| hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"}, |
| {width="14",alignment="-1",col_name="type",colhdr="Type"}, |
| {width="4",alignment="-1",col_name="disp",colhdr="Disp"}, |
| {width="3",alignment="-1",col_name="enabled",colhdr="Enb"}, |
| {width="10",alignment="-1",col_name="addr",colhdr="Address"}, |
| {width="40",alignment="2",col_name="what",colhdr="What"}], |
| body=[]} |
| (gdb) |
| |
| The `-break-passcount' Command |
| ------------------------------ |
| |
| Synopsis |
| ........ |
| |
| -break-passcount TRACEPOINT-NUMBER PASSCOUNT |
| |
| Set the passcount for tracepoint TRACEPOINT-NUMBER to PASSCOUNT. If |
| the breakpoint referred to by TRACEPOINT-NUMBER is not a tracepoint, |
| error is emitted. This corresponds to CLI command `passcount'. |
| |
| The `-break-watch' Command |
| -------------------------- |
| |
| Synopsis |
| ........ |
| |
| -break-watch [ -a | -r ] |
| |
| Create a watchpoint. With the `-a' option it will create an |
| "access" watchpoint, i.e., a watchpoint that triggers either on a read |
| from or on a write to the memory location. With the `-r' option, the |
| watchpoint created is a "read" watchpoint, i.e., it will trigger only |
| when the memory location is accessed for reading. Without either of |
| the options, the watchpoint created is a regular watchpoint, i.e., it |
| will trigger when the memory location is accessed for writing. *Note |
| Setting Watchpoints: Set Watchpoints. |
| |
| Note that `-break-list' will report a single list of watchpoints and |
| breakpoints inserted. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB commands are `watch', `awatch', and `rwatch'. |
| |
| Example |
| ....... |
| |
| Setting a watchpoint on a variable in the `main' function: |
| |
| (gdb) |
| -break-watch x |
| ^done,wpt={number="2",exp="x"} |
| (gdb) |
| -exec-continue |
| ^running |
| (gdb) |
| *stopped,reason="watchpoint-trigger",wpt={number="2",exp="x"}, |
| value={old="-268439212",new="55"}, |
| frame={func="main",args=[],file="recursive2.c", |
| fullname="/home/foo/bar/recursive2.c",line="5"} |
| (gdb) |
| |
| Setting a watchpoint on a variable local to a function. GDB will |
| stop the program execution twice: first for the variable changing |
| value, then for the watchpoint going out of scope. |
| |
| (gdb) |
| -break-watch C |
| ^done,wpt={number="5",exp="C"} |
| (gdb) |
| -exec-continue |
| ^running |
| (gdb) |
| *stopped,reason="watchpoint-trigger", |
| wpt={number="5",exp="C"},value={old="-276895068",new="3"}, |
| frame={func="callee4",args=[], |
| file="../../../devo/gdb/testsuite/gdb.mi/basics.c", |
| fullname="/home/foo/bar/devo/gdb/testsuite/gdb.mi/basics.c",line="13"} |
| (gdb) |
| -exec-continue |
| ^running |
| (gdb) |
| *stopped,reason="watchpoint-scope",wpnum="5", |
| frame={func="callee3",args=[{name="strarg", |
| value="0x11940 \"A string argument.\""}], |
| file="../../../devo/gdb/testsuite/gdb.mi/basics.c", |
| fullname="/home/foo/bar/devo/gdb/testsuite/gdb.mi/basics.c",line="18"} |
| (gdb) |
| |
| Listing breakpoints and watchpoints, at different points in the |
| program execution. Note that once the watchpoint goes out of scope, it |
| is deleted. |
| |
| (gdb) |
| -break-watch C |
| ^done,wpt={number="2",exp="C"} |
| (gdb) |
| -break-list |
| ^done,BreakpointTable={nr_rows="2",nr_cols="6", |
| hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"}, |
| {width="14",alignment="-1",col_name="type",colhdr="Type"}, |
| {width="4",alignment="-1",col_name="disp",colhdr="Disp"}, |
| {width="3",alignment="-1",col_name="enabled",colhdr="Enb"}, |
| {width="10",alignment="-1",col_name="addr",colhdr="Address"}, |
| {width="40",alignment="2",col_name="what",colhdr="What"}], |
| body=[bkpt={number="1",type="breakpoint",disp="keep",enabled="y", |
| addr="0x00010734",func="callee4", |
| file="../../../devo/gdb/testsuite/gdb.mi/basics.c", |
| fullname="/home/foo/devo/gdb/testsuite/gdb.mi/basics.c"line="8",thread-groups=["i1"], |
| times="1"}, |
| bkpt={number="2",type="watchpoint",disp="keep", |
| enabled="y",addr="",what="C",thread-groups=["i1"],times="0"}]} |
| (gdb) |
| -exec-continue |
| ^running |
| (gdb) |
| *stopped,reason="watchpoint-trigger",wpt={number="2",exp="C"}, |
| value={old="-276895068",new="3"}, |
| frame={func="callee4",args=[], |
| file="../../../devo/gdb/testsuite/gdb.mi/basics.c", |
| fullname="/home/foo/bar/devo/gdb/testsuite/gdb.mi/basics.c",line="13"} |
| (gdb) |
| -break-list |
| ^done,BreakpointTable={nr_rows="2",nr_cols="6", |
| hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"}, |
| {width="14",alignment="-1",col_name="type",colhdr="Type"}, |
| {width="4",alignment="-1",col_name="disp",colhdr="Disp"}, |
| {width="3",alignment="-1",col_name="enabled",colhdr="Enb"}, |
| {width="10",alignment="-1",col_name="addr",colhdr="Address"}, |
| {width="40",alignment="2",col_name="what",colhdr="What"}], |
| body=[bkpt={number="1",type="breakpoint",disp="keep",enabled="y", |
| addr="0x00010734",func="callee4", |
| file="../../../devo/gdb/testsuite/gdb.mi/basics.c", |
| fullname="/home/foo/devo/gdb/testsuite/gdb.mi/basics.c",line="8",thread-groups=["i1"], |
| times="1"}, |
| bkpt={number="2",type="watchpoint",disp="keep", |
| enabled="y",addr="",what="C",thread-groups=["i1"],times="-5"}]} |
| (gdb) |
| -exec-continue |
| ^running |
| ^done,reason="watchpoint-scope",wpnum="2", |
| frame={func="callee3",args=[{name="strarg", |
| value="0x11940 \"A string argument.\""}], |
| file="../../../devo/gdb/testsuite/gdb.mi/basics.c", |
| fullname="/home/foo/bar/devo/gdb/testsuite/gdb.mi/basics.c",line="18"} |
| (gdb) |
| -break-list |
| ^done,BreakpointTable={nr_rows="1",nr_cols="6", |
| hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"}, |
| {width="14",alignment="-1",col_name="type",colhdr="Type"}, |
| {width="4",alignment="-1",col_name="disp",colhdr="Disp"}, |
| {width="3",alignment="-1",col_name="enabled",colhdr="Enb"}, |
| {width="10",alignment="-1",col_name="addr",colhdr="Address"}, |
| {width="40",alignment="2",col_name="what",colhdr="What"}], |
| body=[bkpt={number="1",type="breakpoint",disp="keep",enabled="y", |
| addr="0x00010734",func="callee4", |
| file="../../../devo/gdb/testsuite/gdb.mi/basics.c", |
| fullname="/home/foo/devo/gdb/testsuite/gdb.mi/basics.c",line="8", |
| thread-groups=["i1"],times="1"}]} |
| (gdb) |
| |
| |
| File: gdb.info, Node: GDB/MI Catchpoint Commands, Next: GDB/MI Program Context, Prev: GDB/MI Breakpoint Commands, Up: GDB/MI |
| |
| 27.9 GDB/MI Catchpoint Commands |
| =============================== |
| |
| This section documents GDB/MI commands for manipulating catchpoints. |
| |
| * Menu: |
| |
| * Shared Library GDB/MI Catchpoint Commands:: |
| * Ada Exception GDB/MI Catchpoint Commands:: |
| |
| |
| File: gdb.info, Node: Shared Library GDB/MI Catchpoint Commands, Next: Ada Exception GDB/MI Catchpoint Commands, Up: GDB/MI Catchpoint Commands |
| |
| 27.9.1 Shared Library GDB/MI Catchpoints |
| ---------------------------------------- |
| |
| The `-catch-load' Command |
| ------------------------- |
| |
| Synopsis |
| ........ |
| |
| -catch-load [ -t ] [ -d ] REGEXP |
| |
| Add a catchpoint for library load events. If the `-t' option is |
| used, the catchpoint is a temporary one (*note Setting Breakpoints: Set |
| Breaks.). If the `-d' option is used, the catchpoint is created in a |
| disabled state. The `regexp' argument is a regular expression used to |
| match the name of the loaded library. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `catch load'. |
| |
| Example |
| ....... |
| |
| -catch-load -t foo.so |
| ^done,bkpt={number="1",type="catchpoint",disp="del",enabled="y", |
| what="load of library matching foo.so",catch-type="load",times="0"} |
| (gdb) |
| |
| The `-catch-unload' Command |
| --------------------------- |
| |
| Synopsis |
| ........ |
| |
| -catch-unload [ -t ] [ -d ] REGEXP |
| |
| Add a catchpoint for library unload events. If the `-t' option is |
| used, the catchpoint is a temporary one (*note Setting Breakpoints: Set |
| Breaks.). If the `-d' option is used, the catchpoint is created in a |
| disabled state. The `regexp' argument is a regular expression used to |
| match the name of the unloaded library. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `catch unload'. |
| |
| Example |
| ....... |
| |
| -catch-unload -d bar.so |
| ^done,bkpt={number="2",type="catchpoint",disp="keep",enabled="n", |
| what="load of library matching bar.so",catch-type="unload",times="0"} |
| (gdb) |
| |
| |
| File: gdb.info, Node: Ada Exception GDB/MI Catchpoint Commands, Prev: Shared Library GDB/MI Catchpoint Commands, Up: GDB/MI Catchpoint Commands |
| |
| 27.9.2 Ada Exception GDB/MI Catchpoints |
| --------------------------------------- |
| |
| The following GDB/MI commands can be used to create catchpoints that |
| stop the execution when Ada exceptions are being raised. |
| |
| The `-catch-assert' Command |
| --------------------------- |
| |
| Synopsis |
| ........ |
| |
| -catch-assert [ -c CONDITION] [ -d ] [ -t ] |
| |
| Add a catchpoint for failed Ada assertions. |
| |
| The possible optional parameters for this command are: |
| |
| `-c CONDITION' |
| Make the catchpoint conditional on CONDITION. |
| |
| `-d' |
| Create a disabled catchpoint. |
| |
| `-t' |
| Create a temporary catchpoint. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `catch assert'. |
| |
| Example |
| ....... |
| |
| -catch-assert |
| ^done,bkptno="5",bkpt={number="5",type="breakpoint",disp="keep", |
| enabled="y",addr="0x0000000000404888",what="failed Ada assertions", |
| thread-groups=["i1"],times="0", |
| original-location="__gnat_debug_raise_assert_failure"} |
| (gdb) |
| |
| The `-catch-exception' Command |
| ------------------------------ |
| |
| Synopsis |
| ........ |
| |
| -catch-exception [ -c CONDITION] [ -d ] [ -e EXCEPTION-NAME ] |
| [ -t ] [ -u ] |
| |
| Add a catchpoint stopping when Ada exceptions are raised. By |
| default, the command stops the program when any Ada exception gets |
| raised. But it is also possible, by using some of the optional |
| parameters described below, to create more selective catchpoints. |
| |
| The possible optional parameters for this command are: |
| |
| `-c CONDITION' |
| Make the catchpoint conditional on CONDITION. |
| |
| `-d' |
| Create a disabled catchpoint. |
| |
| `-e EXCEPTION-NAME' |
| Only stop when EXCEPTION-NAME is raised. This option cannot be |
| used combined with `-u'. |
| |
| `-t' |
| Create a temporary catchpoint. |
| |
| `-u' |
| Stop only when an unhandled exception gets raised. This option |
| cannot be used combined with `-e'. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB commands are `catch exception' and `catch |
| exception unhandled'. |
| |
| Example |
| ....... |
| |
| -catch-exception -e Program_Error |
| ^done,bkptno="4",bkpt={number="4",type="breakpoint",disp="keep", |
| enabled="y",addr="0x0000000000404874", |
| what="`Program_Error' Ada exception", thread-groups=["i1"], |
| times="0",original-location="__gnat_debug_raise_exception"} |
| (gdb) |
| |
| |
| File: gdb.info, Node: GDB/MI Program Context, Next: GDB/MI Thread Commands, Prev: GDB/MI Catchpoint Commands, Up: GDB/MI |
| |
| 27.10 GDB/MI Program Context |
| ============================= |
| |
| The `-exec-arguments' Command |
| ----------------------------- |
| |
| Synopsis |
| ........ |
| |
| -exec-arguments ARGS |
| |
| Set the inferior program arguments, to be used in the next |
| `-exec-run'. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `set args'. |
| |
| Example |
| ....... |
| |
| (gdb) |
| -exec-arguments -v word |
| ^done |
| (gdb) |
| |
| The `-environment-cd' Command |
| ----------------------------- |
| |
| Synopsis |
| ........ |
| |
| -environment-cd PATHDIR |
| |
| Set GDB's working directory. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `cd'. |
| |
| Example |
| ....... |
| |
| (gdb) |
| -environment-cd /kwikemart/marge/ezannoni/flathead-dev/devo/gdb |
| ^done |
| (gdb) |
| |
| The `-environment-directory' Command |
| ------------------------------------ |
| |
| Synopsis |
| ........ |
| |
| -environment-directory [ -r ] [ PATHDIR ]+ |
| |
| Add directories PATHDIR to beginning of search path for source files. |
| If the `-r' option is used, the search path is reset to the default |
| search path. If directories PATHDIR are supplied in addition to the |
| `-r' option, the search path is first reset and then addition occurs as |
| normal. Multiple directories may be specified, separated by blanks. |
| Specifying multiple directories in a single command results in the |
| directories added to the beginning of the search path in the same order |
| they were presented in the command. If blanks are needed as part of a |
| directory name, double-quotes should be used around the name. In the |
| command output, the path will show up separated by the system |
| directory-separator character. The directory-separator character must |
| not be used in any directory name. If no directories are specified, |
| the current search path is displayed. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `dir'. |
| |
| Example |
| ....... |
| |
| (gdb) |
| -environment-directory /kwikemart/marge/ezannoni/flathead-dev/devo/gdb |
| ^done,source-path="/kwikemart/marge/ezannoni/flathead-dev/devo/gdb:$cdir:$cwd" |
| (gdb) |
| -environment-directory "" |
| ^done,source-path="/kwikemart/marge/ezannoni/flathead-dev/devo/gdb:$cdir:$cwd" |
| (gdb) |
| -environment-directory -r /home/jjohnstn/src/gdb /usr/src |
| ^done,source-path="/home/jjohnstn/src/gdb:/usr/src:$cdir:$cwd" |
| (gdb) |
| -environment-directory -r |
| ^done,source-path="$cdir:$cwd" |
| (gdb) |
| |
| The `-environment-path' Command |
| ------------------------------- |
| |
| Synopsis |
| ........ |
| |
| -environment-path [ -r ] [ PATHDIR ]+ |
| |
| Add directories PATHDIR to beginning of search path for object files. |
| If the `-r' option is used, the search path is reset to the original |
| search path that existed at gdb start-up. If directories PATHDIR are |
| supplied in addition to the `-r' option, the search path is first reset |
| and then addition occurs as normal. Multiple directories may be |
| specified, separated by blanks. Specifying multiple directories in a |
| single command results in the directories added to the beginning of the |
| search path in the same order they were presented in the command. If |
| blanks are needed as part of a directory name, double-quotes should be |
| used around the name. In the command output, the path will show up |
| separated by the system directory-separator character. The |
| directory-separator character must not be used in any directory name. |
| If no directories are specified, the current path is displayed. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `path'. |
| |
| Example |
| ....... |
| |
| (gdb) |
| -environment-path |
| ^done,path="/usr/bin" |
| (gdb) |
| -environment-path /kwikemart/marge/ezannoni/flathead-dev/ppc-eabi/gdb /bin |
| ^done,path="/kwikemart/marge/ezannoni/flathead-dev/ppc-eabi/gdb:/bin:/usr/bin" |
| (gdb) |
| -environment-path -r /usr/local/bin |
| ^done,path="/usr/local/bin:/usr/bin" |
| (gdb) |
| |
| The `-environment-pwd' Command |
| ------------------------------ |
| |
| Synopsis |
| ........ |
| |
| -environment-pwd |
| |
| Show the current working directory. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `pwd'. |
| |
| Example |
| ....... |
| |
| (gdb) |
| -environment-pwd |
| ^done,cwd="/kwikemart/marge/ezannoni/flathead-dev/devo/gdb" |
| (gdb) |
| |
| |
| File: gdb.info, Node: GDB/MI Thread Commands, Next: GDB/MI Ada Tasking Commands, Prev: GDB/MI Program Context, Up: GDB/MI |
| |
| 27.11 GDB/MI Thread Commands |
| ============================ |
| |
| The `-thread-info' Command |
| -------------------------- |
| |
| Synopsis |
| ........ |
| |
| -thread-info [ THREAD-ID ] |
| |
| Reports information about either a specific thread, if the THREAD-ID |
| parameter is present, or about all threads. When printing information |
| about all threads, also reports the current thread. |
| |
| GDB Command |
| ........... |
| |
| The `info thread' command prints the same information about all threads. |
| |
| Result |
| ...... |
| |
| The result is a list of threads. The following attributes are defined |
| for a given thread: |
| |
| `current' |
| This field exists only for the current thread. It has the value |
| `*'. |
| |
| `id' |
| The identifier that GDB uses to refer to the thread. |
| |
| `target-id' |
| The identifier that the target uses to refer to the thread. |
| |
| `details' |
| Extra information about the thread, in a target-specific format. |
| This field is optional. |
| |
| `name' |
| The name of the thread. If the user specified a name using the |
| `thread name' command, then this name is given. Otherwise, if GDB |
| can extract the thread name from the target, then that name is |
| given. If GDB cannot find the thread name, then this field is |
| omitted. |
| |
| `frame' |
| The stack frame currently executing in the thread. |
| |
| `state' |
| The thread's state. The `state' field may have the following |
| values: |
| |
| `stopped' |
| The thread is stopped. Frame information is available for |
| stopped threads. |
| |
| `running' |
| The thread is running. There's no frame information for |
| running threads. |
| |
| |
| `core' |
| If GDB can find the CPU core on which this thread is running, then |
| this field is the core identifier. This field is optional. |
| |
| |
| Example |
| ....... |
| |
| -thread-info |
| ^done,threads=[ |
| {id="2",target-id="Thread 0xb7e14b90 (LWP 21257)", |
| frame={level="0",addr="0xffffe410",func="__kernel_vsyscall", |
| args=[]},state="running"}, |
| {id="1",target-id="Thread 0xb7e156b0 (LWP 21254)", |
| frame={level="0",addr="0x0804891f",func="foo", |
| args=[{name="i",value="10"}], |
| file="/tmp/a.c",fullname="/tmp/a.c",line="158"}, |
| state="running"}], |
| current-thread-id="1" |
| (gdb) |
| |
| The `-thread-list-ids' Command |
| ------------------------------ |
| |
| Synopsis |
| ........ |
| |
| -thread-list-ids |
| |
| Produces a list of the currently known GDB thread ids. At the end |
| of the list it also prints the total number of such threads. |
| |
| This command is retained for historical reasons, the `-thread-info' |
| command should be used instead. |
| |
| GDB Command |
| ........... |
| |
| Part of `info threads' supplies the same information. |
| |
| Example |
| ....... |
| |
| (gdb) |
| -thread-list-ids |
| ^done,thread-ids={thread-id="3",thread-id="2",thread-id="1"}, |
| current-thread-id="1",number-of-threads="3" |
| (gdb) |
| |
| The `-thread-select' Command |
| ---------------------------- |
| |
| Synopsis |
| ........ |
| |
| -thread-select THREADNUM |
| |
| Make THREADNUM the current thread. It prints the number of the new |
| current thread, and the topmost frame for that thread. |
| |
| This command is deprecated in favor of explicitly using the |
| `--thread' option to each command. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `thread'. |
| |
| Example |
| ....... |
| |
| (gdb) |
| -exec-next |
| ^running |
| (gdb) |
| *stopped,reason="end-stepping-range",thread-id="2",line="187", |
| file="../../../devo/gdb/testsuite/gdb.threads/linux-dp.c" |
| (gdb) |
| -thread-list-ids |
| ^done, |
| thread-ids={thread-id="3",thread-id="2",thread-id="1"}, |
| number-of-threads="3" |
| (gdb) |
| -thread-select 3 |
| ^done,new-thread-id="3", |
| frame={level="0",func="vprintf", |
| args=[{name="format",value="0x8048e9c \"%*s%c %d %c\\n\""}, |
| {name="arg",value="0x2"}],file="vprintf.c",line="31"} |
| (gdb) |
| |
| |
| File: gdb.info, Node: GDB/MI Ada Tasking Commands, Next: GDB/MI Program Execution, Prev: GDB/MI Thread Commands, Up: GDB/MI |
| |
| 27.12 GDB/MI Ada Tasking Commands |
| ================================= |
| |
| The `-ada-task-info' Command |
| ---------------------------- |
| |
| Synopsis |
| ........ |
| |
| -ada-task-info [ TASK-ID ] |
| |
| Reports information about either a specific Ada task, if the TASK-ID |
| parameter is present, or about all Ada tasks. |
| |
| GDB Command |
| ........... |
| |
| The `info tasks' command prints the same information about all Ada |
| tasks (*note Ada Tasks::). |
| |
| Result |
| ...... |
| |
| The result is a table of Ada tasks. The following columns are defined |
| for each Ada task: |
| |
| `current' |
| This field exists only for the current thread. It has the value |
| `*'. |
| |
| `id' |
| The identifier that GDB uses to refer to the Ada task. |
| |
| `task-id' |
| The identifier that the target uses to refer to the Ada task. |
| |
| `thread-id' |
| The identifier of the thread corresponding to the Ada task. |
| |
| This field should always exist, as Ada tasks are always implemented |
| on top of a thread. But if GDB cannot find this corresponding |
| thread for any reason, the field is omitted. |
| |
| `parent-id' |
| This field exists only when the task was created by another task. |
| In this case, it provides the ID of the parent task. |
| |
| `priority' |
| The base priority of the task. |
| |
| `state' |
| The current state of the task. For a detailed description of the |
| possible states, see *note Ada Tasks::. |
| |
| `name' |
| The name of the task. |
| |
| |
| Example |
| ....... |
| |
| -ada-task-info |
| ^done,tasks={nr_rows="3",nr_cols="8", |
| hdr=[{width="1",alignment="-1",col_name="current",colhdr=""}, |
| {width="3",alignment="1",col_name="id",colhdr="ID"}, |
| {width="9",alignment="1",col_name="task-id",colhdr="TID"}, |
| {width="4",alignment="1",col_name="thread-id",colhdr=""}, |
| {width="4",alignment="1",col_name="parent-id",colhdr="P-ID"}, |
| {width="3",alignment="1",col_name="priority",colhdr="Pri"}, |
| {width="22",alignment="-1",col_name="state",colhdr="State"}, |
| {width="1",alignment="2",col_name="name",colhdr="Name"}], |
| body=[{current="*",id="1",task-id=" 644010",thread-id="1",priority="48", |
| state="Child Termination Wait",name="main_task"}]} |
| (gdb) |
| |
| |
| File: gdb.info, Node: GDB/MI Program Execution, Next: GDB/MI Stack Manipulation, Prev: GDB/MI Ada Tasking Commands, Up: GDB/MI |
| |
| 27.13 GDB/MI Program Execution |
| ============================== |
| |
| These are the asynchronous commands which generate the out-of-band |
| record `*stopped'. Currently GDB only really executes asynchronously |
| with remote targets and this interaction is mimicked in other cases. |
| |
| The `-exec-continue' Command |
| ---------------------------- |
| |
| Synopsis |
| ........ |
| |
| -exec-continue [--reverse] [--all|--thread-group N] |
| |
| Resumes the execution of the inferior program, which will continue |
| to execute until it reaches a debugger stop event. If the `--reverse' |
| option is specified, execution resumes in reverse until it reaches a |
| stop event. Stop events may include |
| * breakpoints or watchpoints |
| |
| * signals or exceptions |
| |
| * the end of the process (or its beginning under `--reverse') |
| |
| * the end or beginning of a replay log if one is being used. |
| In all-stop mode (*note All-Stop Mode::), may resume only one |
| thread, or all threads, depending on the value of the |
| `scheduler-locking' variable. If `--all' is specified, all threads (in |
| all inferiors) will be resumed. The `--all' option is ignored in |
| all-stop mode. If the `--thread-group' options is specified, then all |
| threads in that thread group are resumed. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB corresponding is `continue'. |
| |
| Example |
| ....... |
| |
| -exec-continue |
| ^running |
| (gdb) |
| @Hello world |
| *stopped,reason="breakpoint-hit",disp="keep",bkptno="2",frame={ |
| func="foo",args=[],file="hello.c",fullname="/home/foo/bar/hello.c", |
| line="13"} |
| (gdb) |
| |
| The `-exec-finish' Command |
| -------------------------- |
| |
| Synopsis |
| ........ |
| |
| -exec-finish [--reverse] |
| |
| Resumes the execution of the inferior program until the current |
| function is exited. Displays the results returned by the function. If |
| the `--reverse' option is specified, resumes the reverse execution of |
| the inferior program until the point where current function was called. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `finish'. |
| |
| Example |
| ....... |
| |
| Function returning `void'. |
| |
| -exec-finish |
| ^running |
| (gdb) |
| @hello from foo |
| *stopped,reason="function-finished",frame={func="main",args=[], |
| file="hello.c",fullname="/home/foo/bar/hello.c",line="7"} |
| (gdb) |
| |
| Function returning other than `void'. The name of the internal GDB |
| variable storing the result is printed, together with the value itself. |
| |
| -exec-finish |
| ^running |
| (gdb) |
| *stopped,reason="function-finished",frame={addr="0x000107b0",func="foo", |
| args=[{name="a",value="1"],{name="b",value="9"}}, |
| file="recursive2.c",fullname="/home/foo/bar/recursive2.c",line="14"}, |
| gdb-result-var="$1",return-value="0" |
| (gdb) |
| |
| The `-exec-interrupt' Command |
| ----------------------------- |
| |
| Synopsis |
| ........ |
| |
| -exec-interrupt [--all|--thread-group N] |
| |
| Interrupts the background execution of the target. Note how the |
| token associated with the stop message is the one for the execution |
| command that has been interrupted. The token for the interrupt itself |
| only appears in the `^done' output. If the user is trying to interrupt |
| a non-running program, an error message will be printed. |
| |
| Note that when asynchronous execution is enabled, this command is |
| asynchronous just like other execution commands. That is, first the |
| `^done' response will be printed, and the target stop will be reported |
| after that using the `*stopped' notification. |
| |
| In non-stop mode, only the context thread is interrupted by default. |
| All threads (in all inferiors) will be interrupted if the `--all' |
| option is specified. If the `--thread-group' option is specified, all |
| threads in that group will be interrupted. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `interrupt'. |
| |
| Example |
| ....... |
| |
| (gdb) |
| 111-exec-continue |
| 111^running |
| |
| (gdb) |
| 222-exec-interrupt |
| 222^done |
| (gdb) |
| 111*stopped,signal-name="SIGINT",signal-meaning="Interrupt", |
| frame={addr="0x00010140",func="foo",args=[],file="try.c", |
| fullname="/home/foo/bar/try.c",line="13"} |
| (gdb) |
| |
| (gdb) |
| -exec-interrupt |
| ^error,msg="mi_cmd_exec_interrupt: Inferior not executing." |
| (gdb) |
| |
| The `-exec-jump' Command |
| ------------------------ |
| |
| Synopsis |
| ........ |
| |
| -exec-jump LOCATION |
| |
| Resumes execution of the inferior program at the location specified |
| by parameter. *Note Specify Location::, for a description of the |
| different forms of LOCATION. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `jump'. |
| |
| Example |
| ....... |
| |
| -exec-jump foo.c:10 |
| *running,thread-id="all" |
| ^running |
| |
| The `-exec-next' Command |
| ------------------------ |
| |
| Synopsis |
| ........ |
| |
| -exec-next [--reverse] |
| |
| Resumes execution of the inferior program, stopping when the |
| beginning of the next source line is reached. |
| |
| If the `--reverse' option is specified, resumes reverse execution of |
| the inferior program, stopping at the beginning of the previous source |
| line. If you issue this command on the first line of a function, it |
| will take you back to the caller of that function, to the source line |
| where the function was called. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `next'. |
| |
| Example |
| ....... |
| |
| -exec-next |
| ^running |
| (gdb) |
| *stopped,reason="end-stepping-range",line="8",file="hello.c" |
| (gdb) |
| |
| The `-exec-next-instruction' Command |
| ------------------------------------ |
| |
| Synopsis |
| ........ |
| |
| -exec-next-instruction [--reverse] |
| |
| Executes one machine instruction. If the instruction is a function |
| call, continues until the function returns. If the program stops at an |
| instruction in the middle of a source line, the address will be printed |
| as well. |
| |
| If the `--reverse' option is specified, resumes reverse execution of |
| the inferior program, stopping at the previous instruction. If the |
| previously executed instruction was a return from another function, it |
| will continue to execute in reverse until the call to that function |
| (from the current stack frame) is reached. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `nexti'. |
| |
| Example |
| ....... |
| |
| (gdb) |
| -exec-next-instruction |
| ^running |
| |
| (gdb) |
| *stopped,reason="end-stepping-range", |
| addr="0x000100d4",line="5",file="hello.c" |
| (gdb) |
| |
| The `-exec-return' Command |
| -------------------------- |
| |
| Synopsis |
| ........ |
| |
| -exec-return |
| |
| Makes current function return immediately. Doesn't execute the |
| inferior. Displays the new current frame. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `return'. |
| |
| Example |
| ....... |
| |
| (gdb) |
| 200-break-insert callee4 |
| 200^done,bkpt={number="1",addr="0x00010734", |
| file="../../../devo/gdb/testsuite/gdb.mi/basics.c",line="8"} |
| (gdb) |
| 000-exec-run |
| 000^running |
| (gdb) |
| 000*stopped,reason="breakpoint-hit",disp="keep",bkptno="1", |
| frame={func="callee4",args=[], |
| file="../../../devo/gdb/testsuite/gdb.mi/basics.c", |
| fullname="/home/foo/bar/devo/gdb/testsuite/gdb.mi/basics.c",line="8"} |
| (gdb) |
| 205-break-delete |
| 205^done |
| (gdb) |
| 111-exec-return |
| 111^done,frame={level="0",func="callee3", |
| args=[{name="strarg", |
| value="0x11940 \"A string argument.\""}], |
| file="../../../devo/gdb/testsuite/gdb.mi/basics.c", |
| fullname="/home/foo/bar/devo/gdb/testsuite/gdb.mi/basics.c",line="18"} |
| (gdb) |
| |
| The `-exec-run' Command |
| ----------------------- |
| |
| Synopsis |
| ........ |
| |
| -exec-run [ --all | --thread-group N ] [ --start ] |
| |
| Starts execution of the inferior from the beginning. The inferior |
| executes until either a breakpoint is encountered or the program exits. |
| In the latter case the output will include an exit code, if the program |
| has exited exceptionally. |
| |
| When neither the `--all' nor the `--thread-group' option is |
| specified, the current inferior is started. If the `--thread-group' |
| option is specified, it should refer to a thread group of type |
| `process', and that thread group will be started. If the `--all' |
| option is specified, then all inferiors will be started. |
| |
| Using the `--start' option instructs the debugger to stop the |
| execution at the start of the inferior's main subprogram, following the |
| same behavior as the `start' command (*note Starting::). |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `run'. |
| |
| Examples |
| ........ |
| |
| (gdb) |
| -break-insert main |
| ^done,bkpt={number="1",addr="0x0001072c",file="recursive2.c",line="4"} |
| (gdb) |
| -exec-run |
| ^running |
| (gdb) |
| *stopped,reason="breakpoint-hit",disp="keep",bkptno="1", |
| frame={func="main",args=[],file="recursive2.c", |
| fullname="/home/foo/bar/recursive2.c",line="4"} |
| (gdb) |
| |
| Program exited normally: |
| |
| (gdb) |
| -exec-run |
| ^running |
| (gdb) |
| x = 55 |
| *stopped,reason="exited-normally" |
| (gdb) |
| |
| Program exited exceptionally: |
| |
| (gdb) |
| -exec-run |
| ^running |
| (gdb) |
| x = 55 |
| *stopped,reason="exited",exit-code="01" |
| (gdb) |
| |
| Another way the program can terminate is if it receives a signal |
| such as `SIGINT'. In this case, GDB/MI displays this: |
| |
| (gdb) |
| *stopped,reason="exited-signalled",signal-name="SIGINT", |
| signal-meaning="Interrupt" |
| |
| The `-exec-step' Command |
| ------------------------ |
| |
| Synopsis |
| ........ |
| |
| -exec-step [--reverse] |
| |
| Resumes execution of the inferior program, stopping when the |
| beginning of the next source line is reached, if the next source line |
| is not a function call. If it is, stop at the first instruction of the |
| called function. If the `--reverse' option is specified, resumes |
| reverse execution of the inferior program, stopping at the beginning of |
| the previously executed source line. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `step'. |
| |
| Example |
| ....... |
| |
| Stepping into a function: |
| |
| -exec-step |
| ^running |
| (gdb) |
| *stopped,reason="end-stepping-range", |
| frame={func="foo",args=[{name="a",value="10"}, |
| {name="b",value="0"}],file="recursive2.c", |
| fullname="/home/foo/bar/recursive2.c",line="11"} |
| (gdb) |
| |
| Regular stepping: |
| |
| -exec-step |
| ^running |
| (gdb) |
| *stopped,reason="end-stepping-range",line="14",file="recursive2.c" |
| (gdb) |
| |
| The `-exec-step-instruction' Command |
| ------------------------------------ |
| |
| Synopsis |
| ........ |
| |
| -exec-step-instruction [--reverse] |
| |
| Resumes the inferior which executes one machine instruction. If the |
| `--reverse' option is specified, resumes reverse execution of the |
| inferior program, stopping at the previously executed instruction. The |
| output, once GDB has stopped, will vary depending on whether we have |
| stopped in the middle of a source line or not. In the former case, the |
| address at which the program stopped will be printed as well. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `stepi'. |
| |
| Example |
| ....... |
| |
| (gdb) |
| -exec-step-instruction |
| ^running |
| |
| (gdb) |
| *stopped,reason="end-stepping-range", |
| frame={func="foo",args=[],file="try.c", |
| fullname="/home/foo/bar/try.c",line="10"} |
| (gdb) |
| -exec-step-instruction |
| ^running |
| |
| (gdb) |
| *stopped,reason="end-stepping-range", |
| frame={addr="0x000100f4",func="foo",args=[],file="try.c", |
| fullname="/home/foo/bar/try.c",line="10"} |
| (gdb) |
| |
| The `-exec-until' Command |
| ------------------------- |
| |
| Synopsis |
| ........ |
| |
| -exec-until [ LOCATION ] |
| |
| Executes the inferior until the LOCATION specified in the argument |
| is reached. If there is no argument, the inferior executes until a |
| source line greater than the current one is reached. The reason for |
| stopping in this case will be `location-reached'. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `until'. |
| |
| Example |
| ....... |
| |
| (gdb) |
| -exec-until recursive2.c:6 |
| ^running |
| (gdb) |
| x = 55 |
| *stopped,reason="location-reached",frame={func="main",args=[], |
| file="recursive2.c",fullname="/home/foo/bar/recursive2.c",line="6"} |
| (gdb) |
| |
| |
| File: gdb.info, Node: GDB/MI Stack Manipulation, Next: GDB/MI Variable Objects, Prev: GDB/MI Program Execution, Up: GDB/MI |
| |
| 27.14 GDB/MI Stack Manipulation Commands |
| ======================================== |
| |
| The `-enable-frame-filters' Command |
| ----------------------------------- |
| |
| -enable-frame-filters |
| |
| GDB allows Python-based frame filters to affect the output of the MI |
| commands relating to stack traces. As there is no way to implement |
| this in a fully backward-compatible way, a front end must request that |
| this functionality be enabled. |
| |
| Once enabled, this feature cannot be disabled. |
| |
| Note that if Python support has not been compiled into GDB, this |
| command will still succeed (and do nothing). |
| |
| The `-stack-info-frame' Command |
| ------------------------------- |
| |
| Synopsis |
| ........ |
| |
| -stack-info-frame |
| |
| Get info on the selected frame. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `info frame' or `frame' (without |
| arguments). |
| |
| Example |
| ....... |
| |
| (gdb) |
| -stack-info-frame |
| ^done,frame={level="1",addr="0x0001076c",func="callee3", |
| file="../../../devo/gdb/testsuite/gdb.mi/basics.c", |
| fullname="/home/foo/bar/devo/gdb/testsuite/gdb.mi/basics.c",line="17"} |
| (gdb) |
| |
| The `-stack-info-depth' Command |
| ------------------------------- |
| |
| Synopsis |
| ........ |
| |
| -stack-info-depth [ MAX-DEPTH ] |
| |
| Return the depth of the stack. If the integer argument MAX-DEPTH is |
| specified, do not count beyond MAX-DEPTH frames. |
| |
| GDB Command |
| ........... |
| |
| There's no equivalent GDB command. |
| |
| Example |
| ....... |
| |
| For a stack with frame levels 0 through 11: |
| |
| (gdb) |
| -stack-info-depth |
| ^done,depth="12" |
| (gdb) |
| -stack-info-depth 4 |
| ^done,depth="4" |
| (gdb) |
| -stack-info-depth 12 |
| ^done,depth="12" |
| (gdb) |
| -stack-info-depth 11 |
| ^done,depth="11" |
| (gdb) |
| -stack-info-depth 13 |
| ^done,depth="12" |
| (gdb) |
| |
| The `-stack-list-arguments' Command |
| ----------------------------------- |
| |
| Synopsis |
| ........ |
| |
| -stack-list-arguments [ --no-frame-filters ] [ --skip-unavailable ] PRINT-VALUES |
| [ LOW-FRAME HIGH-FRAME ] |
| |
| Display a list of the arguments for the frames between LOW-FRAME and |
| HIGH-FRAME (inclusive). If LOW-FRAME and HIGH-FRAME are not provided, |
| list the arguments for the whole call stack. If the two arguments are |
| equal, show the single frame at the corresponding level. It is an |
| error if LOW-FRAME is larger than the actual number of frames. On the |
| other hand, HIGH-FRAME may be larger than the actual number of frames, |
| in which case only existing frames will be returned. |
| |
| If PRINT-VALUES is 0 or `--no-values', print only the names of the |
| variables; if it is 1 or `--all-values', print also their values; and |
| if it is 2 or `--simple-values', print the name, type and value for |
| simple data types, and the name and type for arrays, structures and |
| unions. If the option `--no-frame-filters' is supplied, then Python |
| frame filters will not be executed. |
| |
| If the `--skip-unavailable' option is specified, arguments that are |
| not available are not listed. Partially available arguments are still |
| displayed, however. |
| |
| Use of this command to obtain arguments in a single frame is |
| deprecated in favor of the `-stack-list-variables' command. |
| |
| GDB Command |
| ........... |
| |
| GDB does not have an equivalent command. `gdbtk' has a `gdb_get_args' |
| command which partially overlaps with the functionality of |
| `-stack-list-arguments'. |
| |
| Example |
| ....... |
| |
| (gdb) |
| -stack-list-frames |
| ^done, |
| stack=[ |
| frame={level="0",addr="0x00010734",func="callee4", |
| file="../../../devo/gdb/testsuite/gdb.mi/basics.c", |
| fullname="/home/foo/bar/devo/gdb/testsuite/gdb.mi/basics.c",line="8"}, |
| frame={level="1",addr="0x0001076c",func="callee3", |
| file="../../../devo/gdb/testsuite/gdb.mi/basics.c", |
| fullname="/home/foo/bar/devo/gdb/testsuite/gdb.mi/basics.c",line="17"}, |
| frame={level="2",addr="0x0001078c",func="callee2", |
| file="../../../devo/gdb/testsuite/gdb.mi/basics.c", |
| fullname="/home/foo/bar/devo/gdb/testsuite/gdb.mi/basics.c",line="22"}, |
| frame={level="3",addr="0x000107b4",func="callee1", |
| file="../../../devo/gdb/testsuite/gdb.mi/basics.c", |
| fullname="/home/foo/bar/devo/gdb/testsuite/gdb.mi/basics.c",line="27"}, |
| frame={level="4",addr="0x000107e0",func="main", |
| file="../../../devo/gdb/testsuite/gdb.mi/basics.c", |
| fullname="/home/foo/bar/devo/gdb/testsuite/gdb.mi/basics.c",line="32"}] |
| (gdb) |
| -stack-list-arguments 0 |
| ^done, |
| stack-args=[ |
| frame={level="0",args=[]}, |
| frame={level="1",args=[name="strarg"]}, |
| frame={level="2",args=[name="intarg",name="strarg"]}, |
| frame={level="3",args=[name="intarg",name="strarg",name="fltarg"]}, |
| frame={level="4",args=[]}] |
| (gdb) |
| -stack-list-arguments 1 |
| ^done, |
| stack-args=[ |
| frame={level="0",args=[]}, |
| frame={level="1", |
| args=[{name="strarg",value="0x11940 \"A string argument.\""}]}, |
| frame={level="2",args=[ |
| {name="intarg",value="2"}, |
| {name="strarg",value="0x11940 \"A string argument.\""}]}, |
| {frame={level="3",args=[ |
| {name="intarg",value="2"}, |
| {name="strarg",value="0x11940 \"A string argument.\""}, |
| {name="fltarg",value="3.5"}]}, |
| frame={level="4",args=[]}] |
| (gdb) |
| -stack-list-arguments 0 2 2 |
| ^done,stack-args=[frame={level="2",args=[name="intarg",name="strarg"]}] |
| (gdb) |
| -stack-list-arguments 1 2 2 |
| ^done,stack-args=[frame={level="2", |
| args=[{name="intarg",value="2"}, |
| {name="strarg",value="0x11940 \"A string argument.\""}]}] |
| (gdb) |
| |
| The `-stack-list-frames' Command |
| -------------------------------- |
| |
| Synopsis |
| ........ |
| |
| -stack-list-frames [ --no-frame-filters LOW-FRAME HIGH-FRAME ] |
| |
| List the frames currently on the stack. For each frame it displays |
| the following info: |
| |
| `LEVEL' |
| The frame number, 0 being the topmost frame, i.e., the innermost |
| function. |
| |
| `ADDR' |
| The `$pc' value for that frame. |
| |
| `FUNC' |
| Function name. |
| |
| `FILE' |
| File name of the source file where the function lives. |
| |
| `FULLNAME' |
| The full file name of the source file where the function lives. |
| |
| `LINE' |
| Line number corresponding to the `$pc'. |
| |
| `FROM' |
| The shared library where this function is defined. This is only |
| given if the frame's function is not known. |
| |
| If invoked without arguments, this command prints a backtrace for the |
| whole stack. If given two integer arguments, it shows the frames whose |
| levels are between the two arguments (inclusive). If the two arguments |
| are equal, it shows the single frame at the corresponding level. It is |
| an error if LOW-FRAME is larger than the actual number of frames. On |
| the other hand, HIGH-FRAME may be larger than the actual number of |
| frames, in which case only existing frames will be returned. If the |
| option `--no-frame-filters' is supplied, then Python frame filters will |
| not be executed. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB commands are `backtrace' and `where'. |
| |
| Example |
| ....... |
| |
| Full stack backtrace: |
| |
| (gdb) |
| -stack-list-frames |
| ^done,stack= |
| [frame={level="0",addr="0x0001076c",func="foo", |
| file="recursive2.c",fullname="/home/foo/bar/recursive2.c",line="11"}, |
| frame={level="1",addr="0x000107a4",func="foo", |
| file="recursive2.c",fullname="/home/foo/bar/recursive2.c",line="14"}, |
| frame={level="2",addr="0x000107a4",func="foo", |
| file="recursive2.c",fullname="/home/foo/bar/recursive2.c",line="14"}, |
| frame={level="3",addr="0x000107a4",func="foo", |
| file="recursive2.c",fullname="/home/foo/bar/recursive2.c",line="14"}, |
| frame={level="4",addr="0x000107a4",func="foo", |
| file="recursive2.c",fullname="/home/foo/bar/recursive2.c",line="14"}, |
| frame={level="5",addr="0x000107a4",func="foo", |
| file="recursive2.c",fullname="/home/foo/bar/recursive2.c",line="14"}, |
| frame={level="6",addr="0x000107a4",func="foo", |
| file="recursive2.c",fullname="/home/foo/bar/recursive2.c",line="14"}, |
| frame={level="7",addr="0x000107a4",func="foo", |
| file="recursive2.c",fullname="/home/foo/bar/recursive2.c",line="14"}, |
| frame={level="8",addr="0x000107a4",func="foo", |
| file="recursive2.c",fullname="/home/foo/bar/recursive2.c",line="14"}, |
| frame={level="9",addr="0x000107a4",func="foo", |
| file="recursive2.c",fullname="/home/foo/bar/recursive2.c",line="14"}, |
| frame={level="10",addr="0x000107a4",func="foo", |
| file="recursive2.c",fullname="/home/foo/bar/recursive2.c",line="14"}, |
| frame={level="11",addr="0x00010738",func="main", |
| file="recursive2.c",fullname="/home/foo/bar/recursive2.c",line="4"}] |
| (gdb) |
| |
| Show frames between LOW_FRAME and HIGH_FRAME: |
| |
| (gdb) |
| -stack-list-frames 3 5 |
| ^done,stack= |
| [frame={level="3",addr="0x000107a4",func="foo", |
| file="recursive2.c",fullname="/home/foo/bar/recursive2.c",line="14"}, |
| frame={level="4",addr="0x000107a4",func="foo", |
| file="recursive2.c",fullname="/home/foo/bar/recursive2.c",line="14"}, |
| frame={level="5",addr="0x000107a4",func="foo", |
| file="recursive2.c",fullname="/home/foo/bar/recursive2.c",line="14"}] |
| (gdb) |
| |
| Show a single frame: |
| |
| (gdb) |
| -stack-list-frames 3 3 |
| ^done,stack= |
| [frame={level="3",addr="0x000107a4",func="foo", |
| file="recursive2.c",fullname="/home/foo/bar/recursive2.c",line="14"}] |
| (gdb) |
| |
| The `-stack-list-locals' Command |
| -------------------------------- |
| |
| Synopsis |
| ........ |
| |
| -stack-list-locals [ --no-frame-filters ] [ --skip-unavailable ] PRINT-VALUES |
| |
| Display the local variable names for the selected frame. If |
| PRINT-VALUES is 0 or `--no-values', print only the names of the |
| variables; if it is 1 or `--all-values', print also their values; and |
| if it is 2 or `--simple-values', print the name, type and value for |
| simple data types, and the name and type for arrays, structures and |
| unions. In this last case, a frontend can immediately display the |
| value of simple data types and create variable objects for other data |
| types when the user wishes to explore their values in more detail. If |
| the option `--no-frame-filters' is supplied, then Python frame filters |
| will not be executed. |
| |
| If the `--skip-unavailable' option is specified, local variables |
| that are not available are not listed. Partially available local |
| variables are still displayed, however. |
| |
| This command is deprecated in favor of the `-stack-list-variables' |
| command. |
| |
| GDB Command |
| ........... |
| |
| `info locals' in GDB, `gdb_get_locals' in `gdbtk'. |
| |
| Example |
| ....... |
| |
| (gdb) |
| -stack-list-locals 0 |
| ^done,locals=[name="A",name="B",name="C"] |
| (gdb) |
| -stack-list-locals --all-values |
| ^done,locals=[{name="A",value="1"},{name="B",value="2"}, |
| {name="C",value="{1, 2, 3}"}] |
| -stack-list-locals --simple-values |
| ^done,locals=[{name="A",type="int",value="1"}, |
| {name="B",type="int",value="2"},{name="C",type="int [3]"}] |
| (gdb) |
| |
| The `-stack-list-variables' Command |
| ----------------------------------- |
| |
| Synopsis |
| ........ |
| |
| -stack-list-variables [ --no-frame-filters ] [ --skip-unavailable ] PRINT-VALUES |
| |
| Display the names of local variables and function arguments for the |
| selected frame. If PRINT-VALUES is 0 or `--no-values', print only the |
| names of the variables; if it is 1 or `--all-values', print also their |
| values; and if it is 2 or `--simple-values', print the name, type and |
| value for simple data types, and the name and type for arrays, |
| structures and unions. If the option `--no-frame-filters' is supplied, |
| then Python frame filters will not be executed. |
| |
| If the `--skip-unavailable' option is specified, local variables and |
| arguments that are not available are not listed. Partially available |
| arguments and local variables are still displayed, however. |
| |
| Example |
| ....... |
| |
| (gdb) |
| -stack-list-variables --thread 1 --frame 0 --all-values |
| ^done,variables=[{name="x",value="11"},{name="s",value="{a = 1, b = 2}"}] |
| (gdb) |
| |
| The `-stack-select-frame' Command |
| --------------------------------- |
| |
| Synopsis |
| ........ |
| |
| -stack-select-frame FRAMENUM |
| |
| Change the selected frame. Select a different frame FRAMENUM on the |
| stack. |
| |
| This command in deprecated in favor of passing the `--frame' option |
| to every command. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB commands are `frame', `up', `down', |
| `select-frame', `up-silent', and `down-silent'. |
| |
| Example |
| ....... |
| |
| (gdb) |
| -stack-select-frame 2 |
| ^done |
| (gdb) |
| |
| |
| File: gdb.info, Node: GDB/MI Variable Objects, Next: GDB/MI Data Manipulation, Prev: GDB/MI Stack Manipulation, Up: GDB/MI |
| |
| 27.15 GDB/MI Variable Objects |
| ============================= |
| |
| Introduction to Variable Objects |
| -------------------------------- |
| |
| Variable objects are "object-oriented" MI interface for examining and |
| changing values of expressions. Unlike some other MI interfaces that |
| work with expressions, variable objects are specifically designed for |
| simple and efficient presentation in the frontend. A variable object |
| is identified by string name. When a variable object is created, the |
| frontend specifies the expression for that variable object. The |
| expression can be a simple variable, or it can be an arbitrary complex |
| expression, and can even involve CPU registers. After creating a |
| variable object, the frontend can invoke other variable object |
| operations--for example to obtain or change the value of a variable |
| object, or to change display format. |
| |
| Variable objects have hierarchical tree structure. Any variable |
| object that corresponds to a composite type, such as structure in C, has |
| a number of child variable objects, for example corresponding to each |
| element of a structure. A child variable object can itself have |
| children, recursively. Recursion ends when we reach leaf variable |
| objects, which always have built-in types. Child variable objects are |
| created only by explicit request, so if a frontend is not interested in |
| the children of a particular variable object, no child will be created. |
| |
| For a leaf variable object it is possible to obtain its value as a |
| string, or set the value from a string. String value can be also |
| obtained for a non-leaf variable object, but it's generally a string |
| that only indicates the type of the object, and does not list its |
| contents. Assignment to a non-leaf variable object is not allowed. |
| |
| A frontend does not need to read the values of all variable objects |
| each time the program stops. Instead, MI provides an update command |
| that lists all variable objects whose values has changed since the last |
| update operation. This considerably reduces the amount of data that |
| must be transferred to the frontend. As noted above, children variable |
| objects are created on demand, and only leaf variable objects have a |
| real value. As result, gdb will read target memory only for leaf |
| variables that frontend has created. |
| |
| The automatic update is not always desirable. For example, a |
| frontend might want to keep a value of some expression for future |
| reference, and never update it. For another example, fetching memory |
| is relatively slow for embedded targets, so a frontend might want to |
| disable automatic update for the variables that are either not visible |
| on the screen, or "closed". This is possible using so called "frozen |
| variable objects". Such variable objects are never implicitly updated. |
| |
| Variable objects can be either "fixed" or "floating". For the fixed |
| variable object, the expression is parsed when the variable object is |
| created, including associating identifiers to specific variables. The |
| meaning of expression never changes. For a floating variable object |
| the values of variables whose names appear in the expressions are |
| re-evaluated every time in the context of the current frame. Consider |
| this example: |
| |
| void do_work(...) |
| { |
| struct work_state state; |
| |
| if (...) |
| do_work(...); |
| } |
| |
| If a fixed variable object for the `state' variable is created in |
| this function, and we enter the recursive call, the variable object |
| will report the value of `state' in the top-level `do_work' invocation. |
| On the other hand, a floating variable object will report the value of |
| `state' in the current frame. |
| |
| If an expression specified when creating a fixed variable object |
| refers to a local variable, the variable object becomes bound to the |
| thread and frame in which the variable object is created. When such |
| variable object is updated, GDB makes sure that the thread/frame |
| combination the variable object is bound to still exists, and |
| re-evaluates the variable object in context of that thread/frame. |
| |
| The following is the complete set of GDB/MI operations defined to |
| access this functionality: |
| |
| *Operation* *Description* |
| `-enable-pretty-printing' enable Python-based pretty-printing |
| `-var-create' create a variable object |
| `-var-delete' delete the variable object and/or its |
| children |
| `-var-set-format' set the display format of this variable |
| `-var-show-format' show the display format of this variable |
| `-var-info-num-children' tells how many children this object has |
| `-var-list-children' return a list of the object's children |
| `-var-info-type' show the type of this variable object |
| `-var-info-expression' print parent-relative expression that this |
| variable object represents |
| `-var-info-path-expression' print full expression that this variable |
| object represents |
| `-var-show-attributes' is this variable editable? does it exist |
| here? |
| `-var-evaluate-expression' get the value of this variable |
| `-var-assign' set the value of this variable |
| `-var-update' update the variable and its children |
| `-var-set-frozen' set frozeness attribute |
| `-var-set-update-range' set range of children to display on update |
| |
| In the next subsection we describe each operation in detail and |
| suggest how it can be used. |
| |
| Description And Use of Operations on Variable Objects |
| ----------------------------------------------------- |
| |
| The `-enable-pretty-printing' Command |
| ------------------------------------- |
| |
| -enable-pretty-printing |
| |
| GDB allows Python-based visualizers to affect the output of the MI |
| variable object commands. However, because there was no way to |
| implement this in a fully backward-compatible way, a front end must |
| request that this functionality be enabled. |
| |
| Once enabled, this feature cannot be disabled. |
| |
| Note that if Python support has not been compiled into GDB, this |
| command will still succeed (and do nothing). |
| |
| This feature is currently (as of GDB 7.0) experimental, and may work |
| differently in future versions of GDB. |
| |
| The `-var-create' Command |
| ------------------------- |
| |
| Synopsis |
| ........ |
| |
| -var-create {NAME | "-"} |
| {FRAME-ADDR | "*" | "@"} EXPRESSION |
| |
| This operation creates a variable object, which allows the |
| monitoring of a variable, the result of an expression, a memory cell or |
| a CPU register. |
| |
| The NAME parameter is the string by which the object can be |
| referenced. It must be unique. If `-' is specified, the varobj system |
| will generate a string "varNNNNNN" automatically. It will be unique |
| provided that one does not specify NAME of that format. The command |
| fails if a duplicate name is found. |
| |
| The frame under which the expression should be evaluated can be |
| specified by FRAME-ADDR. A `*' indicates that the current frame should |
| be used. A `@' indicates that a floating variable object must be |
| created. |
| |
| EXPRESSION is any expression valid on the current language set (must |
| not begin with a `*'), or one of the following: |
| |
| * `*ADDR', where ADDR is the address of a memory cell |
| |
| * `*ADDR-ADDR' -- a memory address range (TBD) |
| |
| * `$REGNAME' -- a CPU register name |
| |
| A varobj's contents may be provided by a Python-based |
| pretty-printer. In this case the varobj is known as a "dynamic |
| varobj". Dynamic varobjs have slightly different semantics in some |
| cases. If the `-enable-pretty-printing' command is not sent, then GDB |
| will never create a dynamic varobj. This ensures backward |
| compatibility for existing clients. |
| |
| Result |
| ...... |
| |
| This operation returns attributes of the newly-created varobj. These |
| are: |
| |
| `name' |
| The name of the varobj. |
| |
| `numchild' |
| The number of children of the varobj. This number is not |
| necessarily reliable for a dynamic varobj. Instead, you must |
| examine the `has_more' attribute. |
| |
| `value' |
| The varobj's scalar value. For a varobj whose type is some sort of |
| aggregate (e.g., a `struct'), or for a dynamic varobj, this value |
| will not be interesting. |
| |
| `type' |
| The varobj's type. This is a string representation of the type, as |
| would be printed by the GDB CLI. If `print object' (*note set |
| print object: Print Settings.) is set to `on', the _actual_ |
| (derived) type of the object is shown rather than the _declared_ |
| one. |
| |
| `thread-id' |
| If a variable object is bound to a specific thread, then this is |
| the thread's identifier. |
| |
| `has_more' |
| For a dynamic varobj, this indicates whether there appear to be any |
| children available. For a non-dynamic varobj, this will be 0. |
| |
| `dynamic' |
| This attribute will be present and have the value `1' if the |
| varobj is a dynamic varobj. If the varobj is not a dynamic varobj, |
| then this attribute will not be present. |
| |
| `displayhint' |
| A dynamic varobj can supply a display hint to the front end. The |
| value comes directly from the Python pretty-printer object's |
| `display_hint' method. *Note Pretty Printing API::. |
| |
| Typical output will look like this: |
| |
| name="NAME",numchild="N",type="TYPE",thread-id="M", |
| has_more="HAS_MORE" |
| |
| The `-var-delete' Command |
| ------------------------- |
| |
| Synopsis |
| ........ |
| |
| -var-delete [ -c ] NAME |
| |
| Deletes a previously created variable object and all of its children. |
| With the `-c' option, just deletes the children. |
| |
| Returns an error if the object NAME is not found. |
| |
| The `-var-set-format' Command |
| ----------------------------- |
| |
| Synopsis |
| ........ |
| |
| -var-set-format NAME FORMAT-SPEC |
| |
| Sets the output format for the value of the object NAME to be |
| FORMAT-SPEC. |
| |
| The syntax for the FORMAT-SPEC is as follows: |
| |
| FORMAT-SPEC ==> |
| {binary | decimal | hexadecimal | octal | natural} |
| |
| The natural format is the default format choosen automatically based |
| on the variable type (like decimal for an `int', hex for pointers, |
| etc.). |
| |
| For a variable with children, the format is set only on the variable |
| itself, and the children are not affected. |
| |
| The `-var-show-format' Command |
| ------------------------------ |
| |
| Synopsis |
| ........ |
| |
| -var-show-format NAME |
| |
| Returns the format used to display the value of the object NAME. |
| |
| FORMAT ==> |
| FORMAT-SPEC |
| |
| The `-var-info-num-children' Command |
| ------------------------------------ |
| |
| Synopsis |
| ........ |
| |
| -var-info-num-children NAME |
| |
| Returns the number of children of a variable object NAME: |
| |
| numchild=N |
| |
| Note that this number is not completely reliable for a dynamic |
| varobj. It will return the current number of children, but more |
| children may be available. |
| |
| The `-var-list-children' Command |
| -------------------------------- |
| |
| Synopsis |
| ........ |
| |
| -var-list-children [PRINT-VALUES] NAME [FROM TO] |
| Return a list of the children of the specified variable object and |
| create variable objects for them, if they do not already exist. With a |
| single argument or if PRINT-VALUES has a value of 0 or `--no-values', |
| print only the names of the variables; if PRINT-VALUES is 1 or |
| `--all-values', also print their values; and if it is 2 or |
| `--simple-values' print the name and value for simple data types and |
| just the name for arrays, structures and unions. |
| |
| FROM and TO, if specified, indicate the range of children to report. |
| If FROM or TO is less than zero, the range is reset and all children |
| will be reported. Otherwise, children starting at FROM (zero-based) |
| and up to and excluding TO will be reported. |
| |
| If a child range is requested, it will only affect the current call |
| to `-var-list-children', but not future calls to `-var-update'. For |
| this, you must instead use `-var-set-update-range'. The intent of this |
| approach is to enable a front end to implement any update approach it |
| likes; for example, scrolling a view may cause the front end to request |
| more children with `-var-list-children', and then the front end could |
| call `-var-set-update-range' with a different range to ensure that |
| future updates are restricted to just the visible items. |
| |
| For each child the following results are returned: |
| |
| NAME |
| Name of the variable object created for this child. |
| |
| EXP |
| The expression to be shown to the user by the front end to |
| designate this child. For example this may be the name of a |
| structure member. |
| |
| For a dynamic varobj, this value cannot be used to form an |
| expression. There is no way to do this at all with a dynamic |
| varobj. |
| |
| For C/C++ structures there are several pseudo children returned to |
| designate access qualifiers. For these pseudo children EXP is |
| `public', `private', or `protected'. In this case the type and |
| value are not present. |
| |
| A dynamic varobj will not report the access qualifying |
| pseudo-children, regardless of the language. This information is |
| not available at all with a dynamic varobj. |
| |
| NUMCHILD |
| Number of children this child has. For a dynamic varobj, this |
| will be 0. |
| |
| TYPE |
| The type of the child. If `print object' (*note set print object: |
| Print Settings.) is set to `on', the _actual_ (derived) type of |
| the object is shown rather than the _declared_ one. |
| |
| VALUE |
| If values were requested, this is the value. |
| |
| THREAD-ID |
| If this variable object is associated with a thread, this is the |
| thread id. Otherwise this result is not present. |
| |
| FROZEN |
| If the variable object is frozen, this variable will be present |
| with a value of 1. |
| |
| DISPLAYHINT |
| A dynamic varobj can supply a display hint to the front end. The |
| value comes directly from the Python pretty-printer object's |
| `display_hint' method. *Note Pretty Printing API::. |
| |
| DYNAMIC |
| This attribute will be present and have the value `1' if the |
| varobj is a dynamic varobj. If the varobj is not a dynamic varobj, |
| then this attribute will not be present. |
| |
| |
| The result may have its own attributes: |
| |
| `displayhint' |
| A dynamic varobj can supply a display hint to the front end. The |
| value comes directly from the Python pretty-printer object's |
| `display_hint' method. *Note Pretty Printing API::. |
| |
| `has_more' |
| This is an integer attribute which is nonzero if there are children |
| remaining after the end of the selected range. |
| |
| Example |
| ....... |
| |
| (gdb) |
| -var-list-children n |
| ^done,numchild=N,children=[child={name=NAME,exp=EXP, |
| numchild=N,type=TYPE},(repeats N times)] |
| (gdb) |
| -var-list-children --all-values n |
| ^done,numchild=N,children=[child={name=NAME,exp=EXP, |
| numchild=N,value=VALUE,type=TYPE},(repeats N times)] |
| |
| The `-var-info-type' Command |
| ---------------------------- |
| |
| Synopsis |
| ........ |
| |
| -var-info-type NAME |
| |
| Returns the type of the specified variable NAME. The type is |
| returned as a string in the same format as it is output by the GDB CLI: |
| |
| type=TYPENAME |
| |
| The `-var-info-expression' Command |
| ---------------------------------- |
| |
| Synopsis |
| ........ |
| |
| -var-info-expression NAME |
| |
| Returns a string that is suitable for presenting this variable |
| object in user interface. The string is generally not valid expression |
| in the current language, and cannot be evaluated. |
| |
| For example, if `a' is an array, and variable object `A' was created |
| for `a', then we'll get this output: |
| |
| (gdb) -var-info-expression A.1 |
| ^done,lang="C",exp="1" |
| |
| Here, the value of `lang' is the language name, which can be found in |
| *note Supported Languages::. |
| |
| Note that the output of the `-var-list-children' command also |
| includes those expressions, so the `-var-info-expression' command is of |
| limited use. |
| |
| The `-var-info-path-expression' Command |
| --------------------------------------- |
| |
| Synopsis |
| ........ |
| |
| -var-info-path-expression NAME |
| |
| Returns an expression that can be evaluated in the current context |
| and will yield the same value that a variable object has. Compare this |
| with the `-var-info-expression' command, which result can be used only |
| for UI presentation. Typical use of the `-var-info-path-expression' |
| command is creating a watchpoint from a variable object. |
| |
| This command is currently not valid for children of a dynamic varobj, |
| and will give an error when invoked on one. |
| |
| For example, suppose `C' is a C++ class, derived from class `Base', |
| and that the `Base' class has a member called `m_size'. Assume a |
| variable `c' is has the type of `C' and a variable object `C' was |
| created for variable `c'. Then, we'll get this output: |
| (gdb) -var-info-path-expression C.Base.public.m_size |
| ^done,path_expr=((Base)c).m_size) |
| |
| The `-var-show-attributes' Command |
| ---------------------------------- |
| |
| Synopsis |
| ........ |
| |
| -var-show-attributes NAME |
| |
| List attributes of the specified variable object NAME: |
| |
| status=ATTR [ ( ,ATTR )* ] |
| |
| where ATTR is `{ { editable | noneditable } | TBD }'. |
| |
| The `-var-evaluate-expression' Command |
| -------------------------------------- |
| |
| Synopsis |
| ........ |
| |
| -var-evaluate-expression [-f FORMAT-SPEC] NAME |
| |
| Evaluates the expression that is represented by the specified |
| variable object and returns its value as a string. The format of the |
| string can be specified with the `-f' option. The possible values of |
| this option are the same as for `-var-set-format' (*note |
| -var-set-format::). If the `-f' option is not specified, the current |
| display format will be used. The current display format can be changed |
| using the `-var-set-format' command. |
| |
| value=VALUE |
| |
| Note that one must invoke `-var-list-children' for a variable before |
| the value of a child variable can be evaluated. |
| |
| The `-var-assign' Command |
| ------------------------- |
| |
| Synopsis |
| ........ |
| |
| -var-assign NAME EXPRESSION |
| |
| Assigns the value of EXPRESSION to the variable object specified by |
| NAME. The object must be `editable'. If the variable's value is |
| altered by the assign, the variable will show up in any subsequent |
| `-var-update' list. |
| |
| Example |
| ....... |
| |
| (gdb) |
| -var-assign var1 3 |
| ^done,value="3" |
| (gdb) |
| -var-update * |
| ^done,changelist=[{name="var1",in_scope="true",type_changed="false"}] |
| (gdb) |
| |
| The `-var-update' Command |
| ------------------------- |
| |
| Synopsis |
| ........ |
| |
| -var-update [PRINT-VALUES] {NAME | "*"} |
| |
| Reevaluate the expressions corresponding to the variable object NAME |
| and all its direct and indirect children, and return the list of |
| variable objects whose values have changed; NAME must be a root |
| variable object. Here, "changed" means that the result of |
| `-var-evaluate-expression' before and after the `-var-update' is |
| different. If `*' is used as the variable object names, all existing |
| variable objects are updated, except for frozen ones (*note |
| -var-set-frozen::). The option PRINT-VALUES determines whether both |
| names and values, or just names are printed. The possible values of |
| this option are the same as for `-var-list-children' (*note |
| -var-list-children::). It is recommended to use the `--all-values' |
| option, to reduce the number of MI commands needed on each program stop. |
| |
| With the `*' parameter, if a variable object is bound to a currently |
| running thread, it will not be updated, without any diagnostic. |
| |
| If `-var-set-update-range' was previously used on a varobj, then |
| only the selected range of children will be reported. |
| |
| `-var-update' reports all the changed varobjs in a tuple named |
| `changelist'. |
| |
| Each item in the change list is itself a tuple holding: |
| |
| `name' |
| The name of the varobj. |
| |
| `value' |
| If values were requested for this update, then this field will be |
| present and will hold the value of the varobj. |
| |
| `in_scope' |
| This field is a string which may take one of three values: |
| |
| `"true"' |
| The variable object's current value is valid. |
| |
| `"false"' |
| The variable object does not currently hold a valid value but |
| it may hold one in the future if its associated expression |
| comes back into scope. |
| |
| `"invalid"' |
| The variable object no longer holds a valid value. This can |
| occur when the executable file being debugged has changed, |
| either through recompilation or by using the GDB `file' |
| command. The front end should normally choose to delete |
| these variable objects. |
| |
| In the future new values may be added to this list so the front |
| should be prepared for this possibility. *Note GDB/MI Development |
| and Front Ends: GDB/MI Development and Front Ends. |
| |
| `type_changed' |
| This is only present if the varobj is still valid. If the type |
| changed, then this will be the string `true'; otherwise it will be |
| `false'. |
| |
| When a varobj's type changes, its children are also likely to have |
| become incorrect. Therefore, the varobj's children are |
| automatically deleted when this attribute is `true'. Also, the |
| varobj's update range, when set using the `-var-set-update-range' |
| command, is unset. |
| |
| `new_type' |
| If the varobj's type changed, then this field will be present and |
| will hold the new type. |
| |
| `new_num_children' |
| For a dynamic varobj, if the number of children changed, or if the |
| type changed, this will be the new number of children. |
| |
| The `numchild' field in other varobj responses is generally not |
| valid for a dynamic varobj - it will show the number of children |
| that GDB knows about, but because dynamic varobjs lazily |
| instantiate their children, this will not reflect the number of |
| children which may be available. |
| |
| The `new_num_children' attribute only reports changes to the |
| number of children known by GDB. This is the only way to detect |
| whether an update has removed children (which necessarily can only |
| happen at the end of the update range). |
| |
| `displayhint' |
| The display hint, if any. |
| |
| `has_more' |
| This is an integer value, which will be 1 if there are more |
| children available outside the varobj's update range. |
| |
| `dynamic' |
| This attribute will be present and have the value `1' if the |
| varobj is a dynamic varobj. If the varobj is not a dynamic varobj, |
| then this attribute will not be present. |
| |
| `new_children' |
| If new children were added to a dynamic varobj within the selected |
| update range (as set by `-var-set-update-range'), then they will |
| be listed in this attribute. |
| |
| Example |
| ....... |
| |
| (gdb) |
| -var-assign var1 3 |
| ^done,value="3" |
| (gdb) |
| -var-update --all-values var1 |
| ^done,changelist=[{name="var1",value="3",in_scope="true", |
| type_changed="false"}] |
| (gdb) |
| |
| The `-var-set-frozen' Command |
| ----------------------------- |
| |
| Synopsis |
| ........ |
| |
| -var-set-frozen NAME FLAG |
| |
| Set the frozenness flag on the variable object NAME. The FLAG |
| parameter should be either `1' to make the variable frozen or `0' to |
| make it unfrozen. If a variable object is frozen, then neither itself, |
| nor any of its children, are implicitly updated by `-var-update' of a |
| parent variable or by `-var-update *'. Only `-var-update' of the |
| variable itself will update its value and values of its children. |
| After a variable object is unfrozen, it is implicitly updated by all |
| subsequent `-var-update' operations. Unfreezing a variable does not |
| update it, only subsequent `-var-update' does. |
| |
| Example |
| ....... |
| |
| (gdb) |
| -var-set-frozen V 1 |
| ^done |
| (gdb) |
| |
| The `-var-set-update-range' command |
| ----------------------------------- |
| |
| Synopsis |
| ........ |
| |
| -var-set-update-range NAME FROM TO |
| |
| Set the range of children to be returned by future invocations of |
| `-var-update'. |
| |
| FROM and TO indicate the range of children to report. If FROM or TO |
| is less than zero, the range is reset and all children will be |
| reported. Otherwise, children starting at FROM (zero-based) and up to |
| and excluding TO will be reported. |
| |
| Example |
| ....... |
| |
| (gdb) |
| -var-set-update-range V 1 2 |
| ^done |
| |
| The `-var-set-visualizer' command |
| --------------------------------- |
| |
| Synopsis |
| ........ |
| |
| -var-set-visualizer NAME VISUALIZER |
| |
| Set a visualizer for the variable object NAME. |
| |
| VISUALIZER is the visualizer to use. The special value `None' means |
| to disable any visualizer in use. |
| |
| If not `None', VISUALIZER must be a Python expression. This |
| expression must evaluate to a callable object which accepts a single |
| argument. GDB will call this object with the value of the varobj NAME |
| as an argument (this is done so that the same Python pretty-printing |
| code can be used for both the CLI and MI). When called, this object |
| must return an object which conforms to the pretty-printing interface |
| (*note Pretty Printing API::). |
| |
| The pre-defined function `gdb.default_visualizer' may be used to |
| select a visualizer by following the built-in process (*note Selecting |
| Pretty-Printers::). This is done automatically when a varobj is |
| created, and so ordinarily is not needed. |
| |
| This feature is only available if Python support is enabled. The MI |
| command `-list-features' (*note GDB/MI Miscellaneous Commands::) can be |
| used to check this. |
| |
| Example |
| ....... |
| |
| Resetting the visualizer: |
| |
| (gdb) |
| -var-set-visualizer V None |
| ^done |
| |
| Reselecting the default (type-based) visualizer: |
| |
| (gdb) |
| -var-set-visualizer V gdb.default_visualizer |
| ^done |
| |
| Suppose `SomeClass' is a visualizer class. A lambda expression can |
| be used to instantiate this class for a varobj: |
| |
| (gdb) |
| -var-set-visualizer V "lambda val: SomeClass()" |
| ^done |
| |
| |
| File: gdb.info, Node: GDB/MI Data Manipulation, Next: GDB/MI Tracepoint Commands, Prev: GDB/MI Variable Objects, Up: GDB/MI |
| |
| 27.16 GDB/MI Data Manipulation |
| ============================== |
| |
| This section describes the GDB/MI commands that manipulate data: |
| examine memory and registers, evaluate expressions, etc. |
| |
| The `-data-disassemble' Command |
| ------------------------------- |
| |
| Synopsis |
| ........ |
| |
| -data-disassemble |
| [ -s START-ADDR -e END-ADDR ] |
| | [ -f FILENAME -l LINENUM [ -n LINES ] ] |
| -- MODE |
| |
| Where: |
| |
| `START-ADDR' |
| is the beginning address (or `$pc') |
| |
| `END-ADDR' |
| is the end address |
| |
| `FILENAME' |
| is the name of the file to disassemble |
| |
| `LINENUM' |
| is the line number to disassemble around |
| |
| `LINES' |
| is the number of disassembly lines to be produced. If it is -1, |
| the whole function will be disassembled, in case no END-ADDR is |
| specified. If END-ADDR is specified as a non-zero value, and |
| LINES is lower than the number of disassembly lines between |
| START-ADDR and END-ADDR, only LINES lines are displayed; if LINES |
| is higher than the number of lines between START-ADDR and |
| END-ADDR, only the lines up to END-ADDR are displayed. |
| |
| `MODE' |
| is either 0 (meaning only disassembly), 1 (meaning mixed source and |
| disassembly), 2 (meaning disassembly with raw opcodes), or 3 |
| (meaning mixed source and disassembly with raw opcodes). |
| |
| Result |
| ...... |
| |
| The result of the `-data-disassemble' command will be a list named |
| `asm_insns', the contents of this list depend on the MODE used with the |
| `-data-disassemble' command. |
| |
| For modes 0 and 2 the `asm_insns' list contains tuples with the |
| following fields: |
| |
| `address' |
| The address at which this instruction was disassembled. |
| |
| `func-name' |
| The name of the function this instruction is within. |
| |
| `offset' |
| The decimal offset in bytes from the start of `func-name'. |
| |
| `inst' |
| The text disassembly for this `address'. |
| |
| `opcodes' |
| This field is only present for mode 2. This contains the raw |
| opcode bytes for the `inst' field. |
| |
| |
| For modes 1 and 3 the `asm_insns' list contains tuples named |
| `src_and_asm_line', each of which has the following fields: |
| |
| `line' |
| The line number within `file'. |
| |
| `file' |
| The file name from the compilation unit. This might be an absolute |
| file name or a relative file name depending on the compile command |
| used. |
| |
| `fullname' |
| Absolute file name of `file'. It is converted to a canonical form |
| using the source file search path (*note Specifying Source |
| Directories: Source Path.) and after resolving all the symbolic |
| links. |
| |
| If the source file is not found this field will contain the path as |
| present in the debug information. |
| |
| `line_asm_insn' |
| This is a list of tuples containing the disassembly for `line' in |
| `file'. The fields of each tuple are the same as for |
| `-data-disassemble' in MODE 0 and 2, so `address', `func-name', |
| `offset', `inst', and optionally `opcodes'. |
| |
| |
| Note that whatever included in the `inst' field, is not manipulated |
| directly by GDB/MI, i.e., it is not possible to adjust its format. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `disassemble'. |
| |
| Example |
| ....... |
| |
| Disassemble from the current value of `$pc' to `$pc + 20': |
| |
| (gdb) |
| -data-disassemble -s $pc -e "$pc + 20" -- 0 |
| ^done, |
| asm_insns=[ |
| {address="0x000107c0",func-name="main",offset="4", |
| inst="mov 2, %o0"}, |
| {address="0x000107c4",func-name="main",offset="8", |
| inst="sethi %hi(0x11800), %o2"}, |
| {address="0x000107c8",func-name="main",offset="12", |
| inst="or %o2, 0x140, %o1\t! 0x11940 <_lib_version+8>"}, |
| {address="0x000107cc",func-name="main",offset="16", |
| inst="sethi %hi(0x11800), %o2"}, |
| {address="0x000107d0",func-name="main",offset="20", |
| inst="or %o2, 0x168, %o4\t! 0x11968 <_lib_version+48>"}] |
| (gdb) |
| |
| Disassemble the whole `main' function. Line 32 is part of `main'. |
| |
| -data-disassemble -f basics.c -l 32 -- 0 |
| ^done,asm_insns=[ |
| {address="0x000107bc",func-name="main",offset="0", |
| inst="save %sp, -112, %sp"}, |
| {address="0x000107c0",func-name="main",offset="4", |
| inst="mov 2, %o0"}, |
| {address="0x000107c4",func-name="main",offset="8", |
| inst="sethi %hi(0x11800), %o2"}, |
| [...] |
| {address="0x0001081c",func-name="main",offset="96",inst="ret "}, |
| {address="0x00010820",func-name="main",offset="100",inst="restore "}] |
| (gdb) |
| |
| Disassemble 3 instructions from the start of `main': |
| |
| (gdb) |
| -data-disassemble -f basics.c -l 32 -n 3 -- 0 |
| ^done,asm_insns=[ |
| {address="0x000107bc",func-name="main",offset="0", |
| inst="save %sp, -112, %sp"}, |
| {address="0x000107c0",func-name="main",offset="4", |
| inst="mov 2, %o0"}, |
| {address="0x000107c4",func-name="main",offset="8", |
| inst="sethi %hi(0x11800), %o2"}] |
| (gdb) |
| |
| Disassemble 3 instructions from the start of `main' in mixed mode: |
| |
| (gdb) |
| -data-disassemble -f basics.c -l 32 -n 3 -- 1 |
| ^done,asm_insns=[ |
| src_and_asm_line={line="31", |
| file="../../../src/gdb/testsuite/gdb.mi/basics.c", |
| fullname="/absolute/path/to/src/gdb/testsuite/gdb.mi/basics.c", |
| line_asm_insn=[{address="0x000107bc", |
| func-name="main",offset="0",inst="save %sp, -112, %sp"}]}, |
| src_and_asm_line={line="32", |
| file="../../../src/gdb/testsuite/gdb.mi/basics.c", |
| fullname="/absolute/path/to/src/gdb/testsuite/gdb.mi/basics.c", |
| line_asm_insn=[{address="0x000107c0", |
| func-name="main",offset="4",inst="mov 2, %o0"}, |
| {address="0x000107c4",func-name="main",offset="8", |
| inst="sethi %hi(0x11800), %o2"}]}] |
| (gdb) |
| |
| The `-data-evaluate-expression' Command |
| --------------------------------------- |
| |
| Synopsis |
| ........ |
| |
| -data-evaluate-expression EXPR |
| |
| Evaluate EXPR as an expression. The expression could contain an |
| inferior function call. The function call will execute synchronously. |
| If the expression contains spaces, it must be enclosed in double quotes. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB commands are `print', `output', and `call'. In |
| `gdbtk' only, there's a corresponding `gdb_eval' command. |
| |
| Example |
| ....... |
| |
| In the following example, the numbers that precede the commands are the |
| "tokens" described in *note GDB/MI Command Syntax: GDB/MI Command |
| Syntax. Notice how GDB/MI returns the same tokens in its output. |
| |
| 211-data-evaluate-expression A |
| 211^done,value="1" |
| (gdb) |
| 311-data-evaluate-expression &A |
| 311^done,value="0xefffeb7c" |
| (gdb) |
| 411-data-evaluate-expression A+3 |
| 411^done,value="4" |
| (gdb) |
| 511-data-evaluate-expression "A + 3" |
| 511^done,value="4" |
| (gdb) |
| |
| The `-data-list-changed-registers' Command |
| ------------------------------------------ |
| |
| Synopsis |
| ........ |
| |
| -data-list-changed-registers |
| |
| Display a list of the registers that have changed. |
| |
| GDB Command |
| ........... |
| |
| GDB doesn't have a direct analog for this command; `gdbtk' has the |
| corresponding command `gdb_changed_register_list'. |
| |
| Example |
| ....... |
| |
| On a PPC MBX board: |
| |
| (gdb) |
| -exec-continue |
| ^running |
| |
| (gdb) |
| *stopped,reason="breakpoint-hit",disp="keep",bkptno="1",frame={ |
| func="main",args=[],file="try.c",fullname="/home/foo/bar/try.c", |
| line="5"} |
| (gdb) |
| -data-list-changed-registers |
| ^done,changed-registers=["0","1","2","4","5","6","7","8","9", |
| "10","11","13","14","15","16","17","18","19","20","21","22","23", |
| "24","25","26","27","28","30","31","64","65","66","67","69"] |
| (gdb) |
| |
| The `-data-list-register-names' Command |
| --------------------------------------- |
| |
| Synopsis |
| ........ |
| |
| -data-list-register-names [ ( REGNO )+ ] |
| |
| Show a list of register names for the current target. If no |
| arguments are given, it shows a list of the names of all the registers. |
| If integer numbers are given as arguments, it will print a list of the |
| names of the registers corresponding to the arguments. To ensure |
| consistency between a register name and its number, the output list may |
| include empty register names. |
| |
| GDB Command |
| ........... |
| |
| GDB does not have a command which corresponds to |
| `-data-list-register-names'. In `gdbtk' there is a corresponding |
| command `gdb_regnames'. |
| |
| Example |
| ....... |
| |
| For the PPC MBX board: |
| (gdb) |
| -data-list-register-names |
| ^done,register-names=["r0","r1","r2","r3","r4","r5","r6","r7", |
| "r8","r9","r10","r11","r12","r13","r14","r15","r16","r17","r18", |
| "r19","r20","r21","r22","r23","r24","r25","r26","r27","r28","r29", |
| "r30","r31","f0","f1","f2","f3","f4","f5","f6","f7","f8","f9", |
| "f10","f11","f12","f13","f14","f15","f16","f17","f18","f19","f20", |
| "f21","f22","f23","f24","f25","f26","f27","f28","f29","f30","f31", |
| "", "pc","ps","cr","lr","ctr","xer"] |
| (gdb) |
| -data-list-register-names 1 2 3 |
| ^done,register-names=["r1","r2","r3"] |
| (gdb) |
| |
| The `-data-list-register-values' Command |
| ---------------------------------------- |
| |
| Synopsis |
| ........ |
| |
| -data-list-register-values |
| [ `--skip-unavailable' ] FMT [ ( REGNO )*] |
| |
| Display the registers' contents. FMT is the format according to |
| which the registers' contents are to be returned, followed by an |
| optional list of numbers specifying the registers to display. A |
| missing list of numbers indicates that the contents of all the |
| registers must be returned. The `--skip-unavailable' option indicates |
| that only the available registers are to be returned. |
| |
| Allowed formats for FMT are: |
| |
| `x' |
| Hexadecimal |
| |
| `o' |
| Octal |
| |
| `t' |
| Binary |
| |
| `d' |
| Decimal |
| |
| `r' |
| Raw |
| |
| `N' |
| Natural |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB commands are `info reg', `info all-reg', and (in |
| `gdbtk') `gdb_fetch_registers'. |
| |
| Example |
| ....... |
| |
| For a PPC MBX board (note: line breaks are for readability only, they |
| don't appear in the actual output): |
| |
| (gdb) |
| -data-list-register-values r 64 65 |
| ^done,register-values=[{number="64",value="0xfe00a300"}, |
| {number="65",value="0x00029002"}] |
| (gdb) |
| -data-list-register-values x |
| ^done,register-values=[{number="0",value="0xfe0043c8"}, |
| {number="1",value="0x3fff88"},{number="2",value="0xfffffffe"}, |
| {number="3",value="0x0"},{number="4",value="0xa"}, |
| {number="5",value="0x3fff68"},{number="6",value="0x3fff58"}, |
| {number="7",value="0xfe011e98"},{number="8",value="0x2"}, |
| {number="9",value="0xfa202820"},{number="10",value="0xfa202808"}, |
| {number="11",value="0x1"},{number="12",value="0x0"}, |
| {number="13",value="0x4544"},{number="14",value="0xffdfffff"}, |
| {number="15",value="0xffffffff"},{number="16",value="0xfffffeff"}, |
| {number="17",value="0xefffffed"},{number="18",value="0xfffffffe"}, |
| {number="19",value="0xffffffff"},{number="20",value="0xffffffff"}, |
| {number="21",value="0xffffffff"},{number="22",value="0xfffffff7"}, |
| {number="23",value="0xffffffff"},{number="24",value="0xffffffff"}, |
| {number="25",value="0xffffffff"},{number="26",value="0xfffffffb"}, |
| {number="27",value="0xffffffff"},{number="28",value="0xf7bfffff"}, |
| {number="29",value="0x0"},{number="30",value="0xfe010000"}, |
| {number="31",value="0x0"},{number="32",value="0x0"}, |
| {number="33",value="0x0"},{number="34",value="0x0"}, |
| {number="35",value="0x0"},{number="36",value="0x0"}, |
| {number="37",value="0x0"},{number="38",value="0x0"}, |
| {number="39",value="0x0"},{number="40",value="0x0"}, |
| {number="41",value="0x0"},{number="42",value="0x0"}, |
| {number="43",value="0x0"},{number="44",value="0x0"}, |
| {number="45",value="0x0"},{number="46",value="0x0"}, |
| {number="47",value="0x0"},{number="48",value="0x0"}, |
| {number="49",value="0x0"},{number="50",value="0x0"}, |
| {number="51",value="0x0"},{number="52",value="0x0"}, |
| {number="53",value="0x0"},{number="54",value="0x0"}, |
| {number="55",value="0x0"},{number="56",value="0x0"}, |
| {number="57",value="0x0"},{number="58",value="0x0"}, |
| {number="59",value="0x0"},{number="60",value="0x0"}, |
| {number="61",value="0x0"},{number="62",value="0x0"}, |
| {number="63",value="0x0"},{number="64",value="0xfe00a300"}, |
| {number="65",value="0x29002"},{number="66",value="0x202f04b5"}, |
| {number="67",value="0xfe0043b0"},{number="68",value="0xfe00b3e4"}, |
| {number="69",value="0x20002b03"}] |
| (gdb) |
| |
| The `-data-read-memory' Command |
| ------------------------------- |
| |
| This command is deprecated, use `-data-read-memory-bytes' instead. |
| |
| Synopsis |
| ........ |
| |
| -data-read-memory [ -o BYTE-OFFSET ] |
| ADDRESS WORD-FORMAT WORD-SIZE |
| NR-ROWS NR-COLS [ ASCHAR ] |
| |
| where: |
| |
| `ADDRESS' |
| An expression specifying the address of the first memory word to be |
| read. Complex expressions containing embedded white space should |
| be quoted using the C convention. |
| |
| `WORD-FORMAT' |
| The format to be used to print the memory words. The notation is |
| the same as for GDB's `print' command (*note Output Formats: |
| Output Formats.). |
| |
| `WORD-SIZE' |
| The size of each memory word in bytes. |
| |
| `NR-ROWS' |
| The number of rows in the output table. |
| |
| `NR-COLS' |
| The number of columns in the output table. |
| |
| `ASCHAR' |
| If present, indicates that each row should include an ASCII dump. |
| The value of ASCHAR is used as a padding character when a byte is |
| not a member of the printable ASCII character set (printable ASCII |
| characters are those whose code is between 32 and 126, |
| inclusively). |
| |
| `BYTE-OFFSET' |
| An offset to add to the ADDRESS before fetching memory. |
| |
| This command displays memory contents as a table of NR-ROWS by |
| NR-COLS words, each word being WORD-SIZE bytes. In total, `NR-ROWS * |
| NR-COLS * WORD-SIZE' bytes are read (returned as `total-bytes'). |
| Should less than the requested number of bytes be returned by the |
| target, the missing words are identified using `N/A'. The number of |
| bytes read from the target is returned in `nr-bytes' and the starting |
| address used to read memory in `addr'. |
| |
| The address of the next/previous row or page is available in |
| `next-row' and `prev-row', `next-page' and `prev-page'. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `x'. `gdbtk' has `gdb_get_mem' memory |
| read command. |
| |
| Example |
| ....... |
| |
| Read six bytes of memory starting at `bytes+6' but then offset by `-6' |
| bytes. Format as three rows of two columns. One byte per word. |
| Display each word in hex. |
| |
| (gdb) |
| 9-data-read-memory -o -6 -- bytes+6 x 1 3 2 |
| 9^done,addr="0x00001390",nr-bytes="6",total-bytes="6", |
| next-row="0x00001396",prev-row="0x0000138e",next-page="0x00001396", |
| prev-page="0x0000138a",memory=[ |
| {addr="0x00001390",data=["0x00","0x01"]}, |
| {addr="0x00001392",data=["0x02","0x03"]}, |
| {addr="0x00001394",data=["0x04","0x05"]}] |
| (gdb) |
| |
| Read two bytes of memory starting at address `shorts + 64' and |
| display as a single word formatted in decimal. |
| |
| (gdb) |
| 5-data-read-memory shorts+64 d 2 1 1 |
| 5^done,addr="0x00001510",nr-bytes="2",total-bytes="2", |
| next-row="0x00001512",prev-row="0x0000150e", |
| next-page="0x00001512",prev-page="0x0000150e",memory=[ |
| {addr="0x00001510",data=["128"]}] |
| (gdb) |
| |
| Read thirty two bytes of memory starting at `bytes+16' and format as |
| eight rows of four columns. Include a string encoding with `x' used as |
| the non-printable character. |
| |
| (gdb) |
| 4-data-read-memory bytes+16 x 1 8 4 x |
| 4^done,addr="0x000013a0",nr-bytes="32",total-bytes="32", |
| next-row="0x000013c0",prev-row="0x0000139c", |
| next-page="0x000013c0",prev-page="0x00001380",memory=[ |
| {addr="0x000013a0",data=["0x10","0x11","0x12","0x13"],ascii="xxxx"}, |
| {addr="0x000013a4",data=["0x14","0x15","0x16","0x17"],ascii="xxxx"}, |
| {addr="0x000013a8",data=["0x18","0x19","0x1a","0x1b"],ascii="xxxx"}, |
| {addr="0x000013ac",data=["0x1c","0x1d","0x1e","0x1f"],ascii="xxxx"}, |
| {addr="0x000013b0",data=["0x20","0x21","0x22","0x23"],ascii=" !\"#"}, |
| {addr="0x000013b4",data=["0x24","0x25","0x26","0x27"],ascii="$%&'"}, |
| {addr="0x000013b8",data=["0x28","0x29","0x2a","0x2b"],ascii="()*+"}, |
| {addr="0x000013bc",data=["0x2c","0x2d","0x2e","0x2f"],ascii=",-./"}] |
| (gdb) |
| |
| The `-data-read-memory-bytes' Command |
| ------------------------------------- |
| |
| Synopsis |
| ........ |
| |
| -data-read-memory-bytes [ -o BYTE-OFFSET ] |
| ADDRESS COUNT |
| |
| where: |
| |
| `ADDRESS' |
| An expression specifying the address of the first memory word to be |
| read. Complex expressions containing embedded white space should |
| be quoted using the C convention. |
| |
| `COUNT' |
| The number of bytes to read. This should be an integer literal. |
| |
| `BYTE-OFFSET' |
| The offsets in bytes relative to ADDRESS at which to start |
| reading. This should be an integer literal. This option is |
| provided so that a frontend is not required to first evaluate |
| address and then perform address arithmetics itself. |
| |
| |
| This command attempts to read all accessible memory regions in the |
| specified range. First, all regions marked as unreadable in the memory |
| map (if one is defined) will be skipped. *Note Memory Region |
| Attributes::. Second, GDB will attempt to read the remaining regions. |
| For each one, if reading full region results in an errors, GDB will try |
| to read a subset of the region. |
| |
| In general, every single byte in the region may be readable or not, |
| and the only way to read every readable byte is to try a read at every |
| address, which is not practical. Therefore, GDB will attempt to read |
| all accessible bytes at either beginning or the end of the region, |
| using a binary division scheme. This heuristic works well for reading |
| accross a memory map boundary. Note that if a region has a readable |
| range that is neither at the beginning or the end, GDB will not read it. |
| |
| The result record (*note GDB/MI Result Records::) that is output of |
| the command includes a field named `memory' whose content is a list of |
| tuples. Each tuple represent a successfully read memory block and has |
| the following fields: |
| |
| `begin' |
| The start address of the memory block, as hexadecimal literal. |
| |
| `end' |
| The end address of the memory block, as hexadecimal literal. |
| |
| `offset' |
| The offset of the memory block, as hexadecimal literal, relative to |
| the start address passed to `-data-read-memory-bytes'. |
| |
| `contents' |
| The contents of the memory block, in hex. |
| |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `x'. |
| |
| Example |
| ....... |
| |
| (gdb) |
| -data-read-memory-bytes &a 10 |
| ^done,memory=[{begin="0xbffff154",offset="0x00000000", |
| end="0xbffff15e", |
| contents="01000000020000000300"}] |
| (gdb) |
| |
| The `-data-write-memory-bytes' Command |
| -------------------------------------- |
| |
| Synopsis |
| ........ |
| |
| -data-write-memory-bytes ADDRESS CONTENTS |
| -data-write-memory-bytes ADDRESS CONTENTS [COUNT] |
| |
| where: |
| |
| `ADDRESS' |
| An expression specifying the address of the first memory word to be |
| read. Complex expressions containing embedded white space should |
| be quoted using the C convention. |
| |
| `CONTENTS' |
| The hex-encoded bytes to write. |
| |
| `COUNT' |
| Optional argument indicating the number of bytes to be written. |
| If COUNT is greater than CONTENTS' length, GDB will repeatedly |
| write CONTENTS until it fills COUNT bytes. |
| |
| |
| GDB Command |
| ........... |
| |
| There's no corresponding GDB command. |
| |
| Example |
| ....... |
| |
| (gdb) |
| -data-write-memory-bytes &a "aabbccdd" |
| ^done |
| (gdb) |
| |
| (gdb) |
| -data-write-memory-bytes &a "aabbccdd" 16e |
| ^done |
| (gdb) |
| |
| |
| File: gdb.info, Node: GDB/MI Tracepoint Commands, Next: GDB/MI Symbol Query, Prev: GDB/MI Data Manipulation, Up: GDB/MI |
| |
| 27.17 GDB/MI Tracepoint Commands |
| ================================ |
| |
| The commands defined in this section implement MI support for |
| tracepoints. For detailed introduction, see *note Tracepoints::. |
| |
| The `-trace-find' Command |
| ------------------------- |
| |
| Synopsis |
| ........ |
| |
| -trace-find MODE [PARAMETERS...] |
| |
| Find a trace frame using criteria defined by MODE and PARAMETERS. |
| The following table lists permissible modes and their parameters. For |
| details of operation, see *note tfind::. |
| |
| `none' |
| No parameters are required. Stops examining trace frames. |
| |
| `frame-number' |
| An integer is required as parameter. Selects tracepoint frame with |
| that index. |
| |
| `tracepoint-number' |
| An integer is required as parameter. Finds next trace frame that |
| corresponds to tracepoint with the specified number. |
| |
| `pc' |
| An address is required as parameter. Finds next trace frame that |
| corresponds to any tracepoint at the specified address. |
| |
| `pc-inside-range' |
| Two addresses are required as parameters. Finds next trace frame |
| that corresponds to a tracepoint at an address inside the |
| specified range. Both bounds are considered to be inside the |
| range. |
| |
| `pc-outside-range' |
| Two addresses are required as parameters. Finds next trace frame |
| that corresponds to a tracepoint at an address outside the |
| specified range. Both bounds are considered to be inside the |
| range. |
| |
| `line' |
| Line specification is required as parameter. *Note Specify |
| Location::. Finds next trace frame that corresponds to a |
| tracepoint at the specified location. |
| |
| |
| If `none' was passed as MODE, the response does not have fields. |
| Otherwise, the response may have the following fields: |
| |
| `found' |
| This field has either `0' or `1' as the value, depending on |
| whether a matching tracepoint was found. |
| |
| `traceframe' |
| The index of the found traceframe. This field is present iff the |
| `found' field has value of `1'. |
| |
| `tracepoint' |
| The index of the found tracepoint. This field is present iff the |
| `found' field has value of `1'. |
| |
| `frame' |
| The information about the frame corresponding to the found trace |
| frame. This field is present only if a trace frame was found. |
| *Note GDB/MI Frame Information::, for description of this field. |
| |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `tfind'. |
| |
| -trace-define-variable |
| ---------------------- |
| |
| Synopsis |
| ........ |
| |
| -trace-define-variable NAME [ VALUE ] |
| |
| Create trace variable NAME if it does not exist. If VALUE is |
| specified, sets the initial value of the specified trace variable to |
| that value. Note that the NAME should start with the `$' character. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `tvariable'. |
| |
| The `-trace-frame-collected' Command |
| ------------------------------------ |
| |
| Synopsis |
| ........ |
| |
| -trace-frame-collected |
| [--var-print-values VAR_PVAL] |
| [--comp-print-values COMP_PVAL] |
| [--registers-format REGFORMAT] |
| [--memory-contents] |
| |
| This command returns the set of collected objects, register names, |
| trace state variable names, memory ranges and computed expressions that |
| have been collected at a particular trace frame. The optional |
| parameters to the command affect the output format in different ways. |
| See the output description table below for more details. |
| |
| The reported names can be used in the normal manner to create |
| varobjs and inspect the objects themselves. The items returned by this |
| command are categorized so that it is clear which is a variable, which |
| is a register, which is a trace state variable, which is a memory range |
| and which is a computed expression. |
| |
| For instance, if the actions were |
| collect myVar, myArray[myIndex], myObj.field, myPtr->field, myCount + 2 |
| collect *(int*)0xaf02bef0@40 |
| |
| the object collected in its entirety would be `myVar'. The object |
| `myArray' would be partially collected, because only the element at |
| index `myIndex' would be collected. The remaining objects would be |
| computed expressions. |
| |
| An example output would be: |
| |
| (gdb) |
| -trace-frame-collected |
| ^done, |
| explicit-variables=[{name="myVar",value="1"}], |
| computed-expressions=[{name="myArray[myIndex]",value="0"}, |
| {name="myObj.field",value="0"}, |
| {name="myPtr->field",value="1"}, |
| {name="myCount + 2",value="3"}, |
| {name="$tvar1 + 1",value="43970027"}], |
| registers=[{number="0",value="0x7fe2c6e79ec8"}, |
| {number="1",value="0x0"}, |
| {number="2",value="0x4"}, |
| ... |
| {number="125",value="0x0"}], |
| tvars=[{name="$tvar1",current="43970026"}], |
| memory=[{address="0x0000000000602264",length="4"}, |
| {address="0x0000000000615bc0",length="4"}] |
| (gdb) |
| |
| Where: |
| |
| `explicit-variables' |
| The set of objects that have been collected in their entirety (as |
| opposed to collecting just a few elements of an array or a few |
| struct members). For each object, its name and value are printed. |
| The `--var-print-values' option affects how or whether the value |
| field is output. If VAR_PVAL is 0, then print only the names; if |
| it is 1, print also their values; and if it is 2, print the name, |
| type and value for simple data types, and the name and type for |
| arrays, structures and unions. |
| |
| `computed-expressions' |
| The set of computed expressions that have been collected at the |
| current trace frame. The `--comp-print-values' option affects |
| this set like the `--var-print-values' option affects the |
| `explicit-variables' set. See above. |
| |
| `registers' |
| The registers that have been collected at the current trace frame. |
| For each register collected, the name and current value are |
| returned. The value is formatted according to the |
| `--registers-format' option. See the `-data-list-register-values' |
| command for a list of the allowed formats. The default is `x'. |
| |
| `tvars' |
| The trace state variables that have been collected at the current |
| trace frame. For each trace state variable collected, the name and |
| current value are returned. |
| |
| `memory' |
| The set of memory ranges that have been collected at the current |
| trace frame. Its content is a list of tuples. Each tuple |
| represents a collected memory range and has the following fields: |
| |
| `address' |
| The start address of the memory range, as hexadecimal literal. |
| |
| `length' |
| The length of the memory range, as decimal literal. |
| |
| `contents' |
| The contents of the memory block, in hex. This field is only |
| present if the `--memory-contents' option is specified. |
| |
| |
| |
| GDB Command |
| ........... |
| |
| There is no corresponding GDB command. |
| |
| Example |
| ....... |
| |
| -trace-list-variables |
| --------------------- |
| |
| Synopsis |
| ........ |
| |
| -trace-list-variables |
| |
| Return a table of all defined trace variables. Each element of the |
| table has the following fields: |
| |
| `name' |
| The name of the trace variable. This field is always present. |
| |
| `initial' |
| The initial value. This is a 64-bit signed integer. This field |
| is always present. |
| |
| `current' |
| The value the trace variable has at the moment. This is a 64-bit |
| signed integer. This field is absent iff current value is not |
| defined, for example if the trace was never run, or is presently |
| running. |
| |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `tvariables'. |
| |
| Example |
| ....... |
| |
| (gdb) |
| -trace-list-variables |
| ^done,trace-variables={nr_rows="1",nr_cols="3", |
| hdr=[{width="15",alignment="-1",col_name="name",colhdr="Name"}, |
| {width="11",alignment="-1",col_name="initial",colhdr="Initial"}, |
| {width="11",alignment="-1",col_name="current",colhdr="Current"}], |
| body=[variable={name="$trace_timestamp",initial="0"} |
| variable={name="$foo",initial="10",current="15"}]} |
| (gdb) |
| |
| -trace-save |
| ----------- |
| |
| Synopsis |
| ........ |
| |
| -trace-save [-r ] FILENAME |
| |
| Saves the collected trace data to FILENAME. Without the `-r' |
| option, the data is downloaded from the target and saved in a local |
| file. With the `-r' option the target is asked to perform the save. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `tsave'. |
| |
| -trace-start |
| ------------ |
| |
| Synopsis |
| ........ |
| |
| -trace-start |
| |
| Starts a tracing experiments. The result of this command does not |
| have any fields. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `tstart'. |
| |
| -trace-status |
| ------------- |
| |
| Synopsis |
| ........ |
| |
| -trace-status |
| |
| Obtains the status of a tracing experiment. The result may include |
| the following fields: |
| |
| `supported' |
| May have a value of either `0', when no tracing operations are |
| supported, `1', when all tracing operations are supported, or |
| `file' when examining trace file. In the latter case, examining |
| of trace frame is possible but new tracing experiement cannot be |
| started. This field is always present. |
| |
| `running' |
| May have a value of either `0' or `1' depending on whether tracing |
| experiement is in progress on target. This field is present if |
| `supported' field is not `0'. |
| |
| `stop-reason' |
| Report the reason why the tracing was stopped last time. This |
| field may be absent iff tracing was never stopped on target yet. |
| The value of `request' means the tracing was stopped as result of |
| the `-trace-stop' command. The value of `overflow' means the |
| tracing buffer is full. The value of `disconnection' means |
| tracing was automatically stopped when GDB has disconnected. The |
| value of `passcount' means tracing was stopped when a tracepoint |
| was passed a maximal number of times for that tracepoint. This |
| field is present if `supported' field is not `0'. |
| |
| `stopping-tracepoint' |
| The number of tracepoint whose passcount as exceeded. This field |
| is present iff the `stop-reason' field has the value of |
| `passcount'. |
| |
| `frames' |
| `frames-created' |
| The `frames' field is a count of the total number of trace frames |
| in the trace buffer, while `frames-created' is the total created |
| during the run, including ones that were discarded, such as when a |
| circular trace buffer filled up. Both fields are optional. |
| |
| `buffer-size' |
| `buffer-free' |
| These fields tell the current size of the tracing buffer and the |
| remaining space. These fields are optional. |
| |
| `circular' |
| The value of the circular trace buffer flag. `1' means that the |
| trace buffer is circular and old trace frames will be discarded if |
| necessary to make room, `0' means that the trace buffer is linear |
| and may fill up. |
| |
| `disconnected' |
| The value of the disconnected tracing flag. `1' means that |
| tracing will continue after GDB disconnects, `0' means that the |
| trace run will stop. |
| |
| `trace-file' |
| The filename of the trace file being examined. This field is |
| optional, and only present when examining a trace file. |
| |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `tstatus'. |
| |
| -trace-stop |
| ----------- |
| |
| Synopsis |
| ........ |
| |
| -trace-stop |
| |
| Stops a tracing experiment. The result of this command has the same |
| fields as `-trace-status', except that the `supported' and `running' |
| fields are not output. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `tstop'. |
| |
| |
| File: gdb.info, Node: GDB/MI Symbol Query, Next: GDB/MI File Commands, Prev: GDB/MI Tracepoint Commands, Up: GDB/MI |
| |
| 27.18 GDB/MI Symbol Query Commands |
| ================================== |
| |
| The `-symbol-list-lines' Command |
| -------------------------------- |
| |
| Synopsis |
| ........ |
| |
| -symbol-list-lines FILENAME |
| |
| Print the list of lines that contain code and their associated |
| program addresses for the given source filename. The entries are |
| sorted in ascending PC order. |
| |
| GDB Command |
| ........... |
| |
| There is no corresponding GDB command. |
| |
| Example |
| ....... |
| |
| (gdb) |
| -symbol-list-lines basics.c |
| ^done,lines=[{pc="0x08048554",line="7"},{pc="0x0804855a",line="8"}] |
| (gdb) |
| |
| |
| File: gdb.info, Node: GDB/MI File Commands, Next: GDB/MI Target Manipulation, Prev: GDB/MI Symbol Query, Up: GDB/MI |
| |
| 27.19 GDB/MI File Commands |
| ========================== |
| |
| This section describes the GDB/MI commands to specify executable file |
| names and to read in and obtain symbol table information. |
| |
| The `-file-exec-and-symbols' Command |
| ------------------------------------ |
| |
| Synopsis |
| ........ |
| |
| -file-exec-and-symbols FILE |
| |
| Specify the executable file to be debugged. This file is the one |
| from which the symbol table is also read. If no file is specified, the |
| command clears the executable and symbol information. If breakpoints |
| are set when using this command with no arguments, GDB will produce |
| error messages. Otherwise, no output is produced, except a completion |
| notification. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `file'. |
| |
| Example |
| ....... |
| |
| (gdb) |
| -file-exec-and-symbols /kwikemart/marge/ezannoni/TRUNK/mbx/hello.mbx |
| ^done |
| (gdb) |
| |
| The `-file-exec-file' Command |
| ----------------------------- |
| |
| Synopsis |
| ........ |
| |
| -file-exec-file FILE |
| |
| Specify the executable file to be debugged. Unlike |
| `-file-exec-and-symbols', the symbol table is _not_ read from this |
| file. If used without argument, GDB clears the information about the |
| executable file. No output is produced, except a completion |
| notification. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `exec-file'. |
| |
| Example |
| ....... |
| |
| (gdb) |
| -file-exec-file /kwikemart/marge/ezannoni/TRUNK/mbx/hello.mbx |
| ^done |
| (gdb) |
| |
| The `-file-list-exec-source-file' Command |
| ----------------------------------------- |
| |
| Synopsis |
| ........ |
| |
| -file-list-exec-source-file |
| |
| List the line number, the current source file, and the absolute path |
| to the current source file for the current executable. The macro |
| information field has a value of `1' or `0' depending on whether or not |
| the file includes preprocessor macro information. |
| |
| GDB Command |
| ........... |
| |
| The GDB equivalent is `info source' |
| |
| Example |
| ....... |
| |
| (gdb) |
| 123-file-list-exec-source-file |
| 123^done,line="1",file="foo.c",fullname="/home/bar/foo.c,macro-info="1" |
| (gdb) |
| |
| The `-file-list-exec-source-files' Command |
| ------------------------------------------ |
| |
| Synopsis |
| ........ |
| |
| -file-list-exec-source-files |
| |
| List the source files for the current executable. |
| |
| It will always output both the filename and fullname (absolute file |
| name) of a source file. |
| |
| GDB Command |
| ........... |
| |
| The GDB equivalent is `info sources'. `gdbtk' has an analogous command |
| `gdb_listfiles'. |
| |
| Example |
| ....... |
| |
| (gdb) |
| -file-list-exec-source-files |
| ^done,files=[ |
| {file=foo.c,fullname=/home/foo.c}, |
| {file=/home/bar.c,fullname=/home/bar.c}, |
| {file=gdb_could_not_find_fullpath.c}] |
| (gdb) |
| |
| The `-file-symbol-file' Command |
| ------------------------------- |
| |
| Synopsis |
| ........ |
| |
| -file-symbol-file FILE |
| |
| Read symbol table info from the specified FILE argument. When used |
| without arguments, clears GDB's symbol table info. No output is |
| produced, except for a completion notification. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `symbol-file'. |
| |
| Example |
| ....... |
| |
| (gdb) |
| -file-symbol-file /kwikemart/marge/ezannoni/TRUNK/mbx/hello.mbx |
| ^done |
| (gdb) |
| |
| |
| File: gdb.info, Node: GDB/MI Target Manipulation, Next: GDB/MI File Transfer Commands, Prev: GDB/MI File Commands, Up: GDB/MI |
| |
| 27.20 GDB/MI Target Manipulation Commands |
| ========================================= |
| |
| The `-target-attach' Command |
| ---------------------------- |
| |
| Synopsis |
| ........ |
| |
| -target-attach PID | GID | FILE |
| |
| Attach to a process PID or a file FILE outside of GDB, or a thread |
| group GID. If attaching to a thread group, the id previously returned |
| by `-list-thread-groups --available' must be used. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `attach'. |
| |
| Example |
| ....... |
| |
| (gdb) |
| -target-attach 34 |
| =thread-created,id="1" |
| *stopped,thread-id="1",frame={addr="0xb7f7e410",func="bar",args=[]} |
| ^done |
| (gdb) |
| |
| The `-target-detach' Command |
| ---------------------------- |
| |
| Synopsis |
| ........ |
| |
| -target-detach [ PID | GID ] |
| |
| Detach from the remote target which normally resumes its execution. |
| If either PID or GID is specified, detaches from either the specified |
| process, or specified thread group. There's no output. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `detach'. |
| |
| Example |
| ....... |
| |
| (gdb) |
| -target-detach |
| ^done |
| (gdb) |
| |
| The `-target-disconnect' Command |
| -------------------------------- |
| |
| Synopsis |
| ........ |
| |
| -target-disconnect |
| |
| Disconnect from the remote target. There's no output and the target |
| is generally not resumed. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `disconnect'. |
| |
| Example |
| ....... |
| |
| (gdb) |
| -target-disconnect |
| ^done |
| (gdb) |
| |
| The `-target-download' Command |
| ------------------------------ |
| |
| Synopsis |
| ........ |
| |
| -target-download |
| |
| Loads the executable onto the remote target. It prints out an |
| update message every half second, which includes the fields: |
| |
| `section' |
| The name of the section. |
| |
| `section-sent' |
| The size of what has been sent so far for that section. |
| |
| `section-size' |
| The size of the section. |
| |
| `total-sent' |
| The total size of what was sent so far (the current and the |
| previous sections). |
| |
| `total-size' |
| The size of the overall executable to download. |
| |
| Each message is sent as status record (*note GDB/MI Output Syntax: |
| GDB/MI Output Syntax.). |
| |
| In addition, it prints the name and size of the sections, as they are |
| downloaded. These messages include the following fields: |
| |
| `section' |
| The name of the section. |
| |
| `section-size' |
| The size of the section. |
| |
| `total-size' |
| The size of the overall executable to download. |
| |
| At the end, a summary is printed. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `load'. |
| |
| Example |
| ....... |
| |
| Note: each status message appears on a single line. Here the messages |
| have been broken down so that they can fit onto a page. |
| |
| (gdb) |
| -target-download |
| +download,{section=".text",section-size="6668",total-size="9880"} |
| +download,{section=".text",section-sent="512",section-size="6668", |
| total-sent="512",total-size="9880"} |
| +download,{section=".text",section-sent="1024",section-size="6668", |
| total-sent="1024",total-size="9880"} |
| +download,{section=".text",section-sent="1536",section-size="6668", |
| total-sent="1536",total-size="9880"} |
| +download,{section=".text",section-sent="2048",section-size="6668", |
| total-sent="2048",total-size="9880"} |
| +download,{section=".text",section-sent="2560",section-size="6668", |
| total-sent="2560",total-size="9880"} |
| +download,{section=".text",section-sent="3072",section-size="6668", |
| total-sent="3072",total-size="9880"} |
| +download,{section=".text",section-sent="3584",section-size="6668", |
| total-sent="3584",total-size="9880"} |
| +download,{section=".text",section-sent="4096",section-size="6668", |
| total-sent="4096",total-size="9880"} |
| +download,{section=".text",section-sent="4608",section-size="6668", |
| total-sent="4608",total-size="9880"} |
| +download,{section=".text",section-sent="5120",section-size="6668", |
| total-sent="5120",total-size="9880"} |
| +download,{section=".text",section-sent="5632",section-size="6668", |
| total-sent="5632",total-size="9880"} |
| +download,{section=".text",section-sent="6144",section-size="6668", |
| total-sent="6144",total-size="9880"} |
| +download,{section=".text",section-sent="6656",section-size="6668", |
| total-sent="6656",total-size="9880"} |
| +download,{section=".init",section-size="28",total-size="9880"} |
| +download,{section=".fini",section-size="28",total-size="9880"} |
| +download,{section=".data",section-size="3156",total-size="9880"} |
| +download,{section=".data",section-sent="512",section-size="3156", |
| total-sent="7236",total-size="9880"} |
| +download,{section=".data",section-sent="1024",section-size="3156", |
| total-sent="7748",total-size="9880"} |
| +download,{section=".data",section-sent="1536",section-size="3156", |
| total-sent="8260",total-size="9880"} |
| +download,{section=".data",section-sent="2048",section-size="3156", |
| total-sent="8772",total-size="9880"} |
| +download,{section=".data",section-sent="2560",section-size="3156", |
| total-sent="9284",total-size="9880"} |
| +download,{section=".data",section-sent="3072",section-size="3156", |
| total-sent="9796",total-size="9880"} |
| ^done,address="0x10004",load-size="9880",transfer-rate="6586", |
| write-rate="429" |
| (gdb) |
| |
| GDB Command |
| ........... |
| |
| No equivalent. |
| |
| Example |
| ....... |
| |
| N.A. |
| |
| The `-target-select' Command |
| ---------------------------- |
| |
| Synopsis |
| ........ |
| |
| -target-select TYPE PARAMETERS ... |
| |
| Connect GDB to the remote target. This command takes two args: |
| |
| `TYPE' |
| The type of target, for instance `remote', etc. |
| |
| `PARAMETERS' |
| Device names, host names and the like. *Note Commands for |
| Managing Targets: Target Commands, for more details. |
| |
| The output is a connection notification, followed by the address at |
| which the target program is, in the following form: |
| |
| ^connected,addr="ADDRESS",func="FUNCTION NAME", |
| args=[ARG LIST] |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `target'. |
| |
| Example |
| ....... |
| |
| (gdb) |
| -target-select remote /dev/ttya |
| ^connected,addr="0xfe00a300",func="??",args=[] |
| (gdb) |
| |
| |
| File: gdb.info, Node: GDB/MI File Transfer Commands, Next: GDB/MI Ada Exceptions Commands, Prev: GDB/MI Target Manipulation, Up: GDB/MI |
| |
| 27.21 GDB/MI File Transfer Commands |
| =================================== |
| |
| The `-target-file-put' Command |
| ------------------------------ |
| |
| Synopsis |
| ........ |
| |
| -target-file-put HOSTFILE TARGETFILE |
| |
| Copy file HOSTFILE from the host system (the machine running GDB) to |
| TARGETFILE on the target system. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `remote put'. |
| |
| Example |
| ....... |
| |
| (gdb) |
| -target-file-put localfile remotefile |
| ^done |
| (gdb) |
| |
| The `-target-file-get' Command |
| ------------------------------ |
| |
| Synopsis |
| ........ |
| |
| -target-file-get TARGETFILE HOSTFILE |
| |
| Copy file TARGETFILE from the target system to HOSTFILE on the host |
| system. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `remote get'. |
| |
| Example |
| ....... |
| |
| (gdb) |
| -target-file-get remotefile localfile |
| ^done |
| (gdb) |
| |
| The `-target-file-delete' Command |
| --------------------------------- |
| |
| Synopsis |
| ........ |
| |
| -target-file-delete TARGETFILE |
| |
| Delete TARGETFILE from the target system. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `remote delete'. |
| |
| Example |
| ....... |
| |
| (gdb) |
| -target-file-delete remotefile |
| ^done |
| (gdb) |
| |
| |
| File: gdb.info, Node: GDB/MI Ada Exceptions Commands, Next: GDB/MI Miscellaneous Commands, Prev: GDB/MI File Transfer Commands, Up: GDB/MI |
| |
| 27.22 Ada Exceptions GDB/MI Commands |
| ==================================== |
| |
| The `-info-ada-exceptions' Command |
| ---------------------------------- |
| |
| Synopsis |
| ........ |
| |
| -info-ada-exceptions [ REGEXP] |
| |
| List all Ada exceptions defined within the program being debugged. |
| With a regular expression REGEXP, only those exceptions whose names |
| match REGEXP are listed. |
| |
| GDB Command |
| ........... |
| |
| The corresponding GDB command is `info exceptions'. |
| |
| Result |
| ...... |
| |
| The result is a table of Ada exceptions. The following columns are |
| defined for each exception: |
| |
| `name' |
| The name of the exception. |
| |
| `address' |
| The address of the exception. |
| |
| |
| Example |
| ....... |
| |
| -info-ada-exceptions aint |
| ^done,ada-exceptions={nr_rows="2",nr_cols="2", |
| hdr=[{width="1",alignment="-1",col_name="name",colhdr="Name"}, |
| {width="1",alignment="-1",col_name="address",colhdr="Address"}], |
| body=[{name="constraint_error",address="0x0000000000613da0"}, |
| {name="const.aint_global_e",address="0x0000000000613b00"}]} |
| |
| Catching Ada Exceptions |
| ----------------------- |
| |
| The commands describing how to ask GDB to stop when a program raises an |
| exception are described at *note Ada Exception GDB/MI Catchpoint |
| Commands::. |
| |