Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

gdb, gdbserver and reading a core dump remotely.

2,222 views
Skip to first unread message

nass

unread,
Sep 5, 2007, 4:16:29 AM9/5/07
to
Hello everyone,
i am reading this book 'Embedded Linux Primer' in case you have heard
it of, and i read about some fascinating capabilities of the gdb.
in 2 independent chapters i read that you can do step by step
debugging remotely, ie have your application running on the target
board along with gdbserver and debug it remotely from your host
(configured for target), just by having a copy of that executable, and
of course gdb. you run that as : gdb <my_prog>

then i also read that if you set: ulimit -c unlinited

you will be getting a full core dump in case the application crashes,
that you can then check using

gdb <my_prog> core

... well i want the best of both worlds: i want to get a core dump on
the target board and be able to either copy the dump to the host pc
and read it, or directly somehow open it with the gdbserver and
connect to it remotely from the host pc....

the book fails to note if the core dump is a separate file, that i can
look for in the same directory , or some other... so i do not know how
to anticipate this file's creation.

Thank you in advance for your help
nass

fjb...@yahoo.com

unread,
Sep 5, 2007, 12:58:47 PM9/5/07
to

Yes, the core dump is just a file called "core" (or something similar,
sometimes something like my_prog.core) which is created in the
program's working directory at the time of the crash. You might begin
by experimenting with them natively on an ordinary Unix box, by
writing a program that crashes; this will give you a better idea of
how they can be used.

In principle, if you have a core dump generated on the target machine,
the binary for the program, and a suitably cross-compiled version of
gdb, you can debug the core dump and inspect the program's state at
the time of the crash. You should not need to use any remote
debugging features for this, since the program will not actually be
run. You only need that if you want to debug the running program,
stopping at breakpoints or single-stepping to examine or change
things.

Core files are created by the operating system, and it's possible that
an embedded system won't support this feature. I assume the target's
OS is something Unix-like, else you wouldn't have posted here, but it
may be stripped down to such an extent that core dumps are removed.
You'll have to test.

nass

unread,
Sep 6, 2007, 4:40:44 AM9/6/07
to

indeed the target os is a debian linux variant.
i did check it... wrote a trivial crashing program run it both on
scratchbox environment (its got a gdb cross compiled for arm) and on
the target arm board.
i did get the core file on the target, copied it back into the
scratchbox and investigated the crash from there. it worked as
expected. Very powerful.. didn't know about it up until now. thank you
very much
nass

0 new messages