--- In "Dan" <> wrote:
>
> I saw some chatter on this when I searched which seemed to suggest
> that statically linking libpthread would solve my problem but it
> doesn't seem to have worked. When I hit the point where my code
> executes pthread_create() it just bombs completely and the gdbserver
> on the target exits with "Child terminated with signal = 0x5".
>
> Can someone give me the "for dummies" version of how to get this set
> up properly? Pretend I have never cross-compiled anything before
> (which happens to be true).
>
> Thanks,
> Dan
>
Hey Dan,
There are a few issues. First, more recent versions of GDB seem to
handle thread debugging much better, so getting a recent version might
help some. I use version 6.8
If you use dynamic linking for the ARM application, when the time
comes to load the shared library, the GDB client on the desktop will
look for the library in the default path (i.e. /lib). Unfortunately,
this means it will usually try to load the library for your PC and not
for the ARM board. Static linking takes care of this problem, since
the libraries are included in the executable, but static linking isn't
always the best option. If not, you can tell the debugger where to
find the correct libraries by setting the 'solib-absolute-prefix' to
point to the library directory of the cross-compiler, like:
(gdb) set solib-absolute-prefix
/opt/crosstool/gcc-4.1.1-glibc-2.3.2/arm-9tdmi-linux-gnu/arm-9tdmi-linux-gnu
(That's all one line)
Sometimes, when the scheduler switches threads it will generate a
SIG32 signal. (I think this may just be a problem when debugging
desktop applications, but I'll mention it anyway.) If so, you would
want to disable them with these commands:
(gdb) handle SIG32 nostop
(gdb) handle SIG32 noprint
The "thread" command lets you switch between threads once they're running.
Another good trick to know is that you can lock the scheduler to
prevent it from switching threads when you're single-stepping through
code. Be careful, though, because you'll deadlock if you try to grab
a resource (mutex, semaphore, etc) that's being held by another
thread, since you've stopped the other threads from running. Use:
(gdb) set schedule-lock on
and
(gdb) set schedule-lock off
And, I've found that occasionally GDB won't single step over some
instructions (often for a good reason), but if you set a breakpoint,
it will run past the line and stop at the breakpoint.
Frank
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|