GDB remote debugging basics

GDB remote debugging basics

[Kevin Buettner]

Eric asked me to send some brief instructions about how to start
a local gdbserver and use GDB to debug against it.

I have a hunch that Oleg is already aware of much of what I will
write about here.

Building some test programs
---------------------------

One of my favorite test programs is the program used in the
gdb.base/break.exp test case from the gdb test suite.  If I need a
multi-threaded test case, I usually use linux-dp from
gdb.threads/linux-dp.exp.

Starting with your CWD (current working directory) in the GDB build
directory, these test programs may be built as follows:

    make check RUNTESTFLAGS="gdb.base/break.exp"
    make check RUNTESTFLAGS="gdb.threads/linux-dp.exp"

Note that in addition to building the test case, the associated test
is also run.  When I ran these test cases prior to composing this
email, I saw no failures.  This is good - if you see any failures
in either of these tests, then something is wrong with GDB.

(Alternately, you can run "make check", which will run the entire
test suite, but that'll take somewhat longer.)

Running gdb and gdbserver in the traditional fashion
----------------------------------------------------

Up until somewhat recently, one would provide the name of
the executable to run on the command line to gdbserver.  E.g,
again starting with the CWD in GDB's build directory:

    ./gdbserver/gdbserver localhost:12345 testsuite/gdb.base/break

The other argument, localhost:12345, specifies the hostname and
port number to which GDB should connect using the "target remote"
command.

On the GDB side of things, GDB may be started as follows:

    ./gdb -nx testsuite/gdb.base/break

(The -nx tells GDB not to load the .gdbinit file.  If you allow GDB to
load this file when situated in the GDB build directory, you'll see
various errors and warnings associated with not being able to find
certain symbols in the test case that you're debugging.)

Once you're at the GDB prompt, the following commands may be used
to connect to gdbserver, and run to main().  Note the use of
"set debug remote 1" which will allow you to observe the interaction
between GDB and gdbserver at the remote protocol level.

    set debug remote 1
    target remote localhost:12345
    break main
    continue

Running gdb and gdbserver using the --multi switch
--------------------------------------------------

When gdbserver is run as shown above, the gdbserver program will
exit once the program exits or is killed.  But it's also possible
to run gdbserver in such a way so that it won't, in theory, exit
when done debugging a program.  This can be done as follows:

    ./gdbserver/gdbserver --multi localhost:12345

Starting GDB is the same as in the previous example:

    ./gdb -nx testsuite/gdb.base/break

But the GDB commands used to connect to gdbserver are different:

    target extended-remote localhost:12345
    break main
    set remote exec-file testsuite/gdb.base/break
    run

(Note that I omitted the "set debug remote 1" in this example.  It's
okay to use it here too if you wish.)

You can make gdbserver exit by issuing the following command
at the GDB prompt:

    monitor exit

gdbserver-side remote protocol debugging
----------------------------------------

gdbserver can be made to show the packets that it sends and receives,
but, IMO, the information displayed by GDB is more readable.  Still,
if you want to try it out, do (from GDB):

    monitor set remote-debug 1

Bugs
----

While playing around with this stuff, I was hoping to show an example
in which I killed "break" and switched to debugging "linux-dp" without
leaving GDB.  This, however, does not work at the moment.  (The behavior
that I saw was that gdbserver exited...)

There are also problems with creating and running a second inferior.
This is due to the fact that remote.c has some global state that
is, unfortunately, shared amongst inferiors.  This could be fixed by
moving that global state to a per-inferior data structure.  I'd be
willing to tackle this problem once I get my patch for multiple sim
instances in.   The nature of the problem in remote.c is similar to
the problem that I addressed with my remote-sim.c patch.  However,
that patch, apparently, needs more work - Pedro just sent me a reply.
In any case, making remote.c work for multiple inferiors is probably
something that my group is interested in anyway.

Kevin

Re: GDB remote debugging basics

[Oleg Nesterov]

On 08/03, Kevin Buettner wrote:
>
> Eric asked me to send some brief instructions about how to start
> a local gdbserver and use GDB to debug against it.
>
> [... snip ...]

Thanks Kevin!

I saved your email for the future reference.

Oleg.

Re: GDB remote debugging basics

[Kevin Buettner]

On Tue, 3 Aug 2010 12:30:16 -0700
Kevin Buettner <kevinb@redhat.com> wrote:

> There are also problems with creating and running a second inferior.
> This is due to the fact that remote.c has some global state that
> is, unfortunately, shared amongst inferiors.

I've studied the code some more.  It should work, though not for the use
case that I had in mind (in which one connects to multiple boards at
once).

Kevin