From: Grant Edwards <grant.b.edwards@gmail.com>
To: buildroot@busybox.net
Subject: [Buildroot] How to get symbolic debugging to work?
Date: Mon, 22 Jun 2009 23:50:20 +0000 (UTC) [thread overview]
Message-ID: <h1p5br$11r$1@ger.gmane.org> (raw)
I've given up temporarily on getting thread support to work in
gdbserver. Now I'm just trying (and failing) to get basic
symbolic debugging to work.
The first problem is how to get enable debug/symbol info in the
libraries (particularly uclibc) on the development host while
still putting stripped ones on the target. If you enable debug
symbols for uclibc, then I get .so files that are too big for
my target. I'm working around that problem with a shell script
that strips libuClibc-*.so and libm-*.so and re-builds the
target filesystem images before copying them to the tftpserver.
It works but it's a PITA.
The second problem is that even when I point gdb to uClibc
with debug symbols, gdb acts clueless. For example, I have a
small C program:
#include <stdio.h>
char buffer[1024];
int main(void)
{
while (1)
{
gets(buffer);
puts(buffer);
}
return 0;
}
I can debug the program find as long as it's executing in
user-application code. I can "next" through the code, set
breakpoints, etc.
However, if I let it run and hit ctrl-C to stop it, it's
blocked in a read() call inside uclibc and gdb acts completely
clueless:
GNU gdb 6.8
[...]
This GDB was configured as "--host=i386-pc-linux-gnu --target=arm-linux-uclibc".
[New Thread 815]
0x40001350 in _start () at ldso/ldso/arm/elfinterp.c:332
332 }
(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x40031914 in ?? ()
(gdb) bt
#0 0x40031914 in ?? ()
If I look at the smaps file for the process, it's clearly in
uclibc.so:
40025000-4008a000 r-xp 00000000 01:00 637 /lib/libuClibc-0.9.30.1.so
Size: 404 kB
Rss: 84 kB
Pss: 10 kB
Shared_Clean: 84 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 0 kB
Referenced: 84 kB
Swap: 0 kB
40031914 is offset 0xc914 in /lib/libuClibc-0.9.30.1.so, and
looking at the symbols in that file shows that's in __libc_read()
0000c5e8 T __libc_pselect
0000c6d8 T ptrace
0000c858 T quotactl
0000c8e0 T __libc_read
==> 0xc914
0000c968 T readlink
0000c9f4 T __libc_readv
0000ca78 T reboot
Why can't gdb figure out that the process is blocked in
__libc_read() and print a proper backtrace?
--
Grant Edwards grante Yow! INSIDE, I have the
at same personality disorder
visi.com as LUCY RICARDO!!
next reply other threads:[~2009-06-22 23:50 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-22 23:50 Grant Edwards [this message]
2009-06-23 18:18 ` [Buildroot] How to get symbolic debugging to work? Grant Edwards
2009-06-24 7:59 ` Sven Neumann
2009-06-24 9:16 ` Bernhard Reutner-Fischer
2009-06-24 14:46 ` Peter Korsgaard
2009-06-24 15:12 ` Bernhard Reutner-Fischer
2009-06-24 14:50 ` Grant Edwards
2009-06-24 14:44 ` Peter Korsgaard
2009-06-24 15:11 ` Grant Edwards
2009-06-24 14:35 ` Sven Neumann
2009-06-24 14:45 ` Grant Edwards
2009-06-24 16:06 ` Sven Neumann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='h1p5br$11r$1@ger.gmane.org' \
--to=grant.b.edwards@gmail.com \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox