Q: GDB - Threads

Q: GDB - Threads

[Vellemans, Noel]

Hi,

Somebody who can point me to a document (URL) that contains some info
about GDB-(server)debugging with threads ?

I'm having problems debugging multithread applications (compiled for
ARM).


Ref to :  http://sourceware.org/ml/gdb/2009-05/msg00137.html



GDB-6.8 (for ARM).

/toolchain_build_arm/gdbhost-6.8/gdb$ ./gdb --v
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show
copying"
and "show warranty" for details.
This GDB was configured as "--host=i386-pc-linux-gnu
--target=arm-linux-uclibc".








Kind Regards,
Noel.
 

Re: Q: GDB - Threads

[Hui Zhu]

http://sourceware.org/gdb/current/onlinedocs/gdb_5.html#SEC28
http://sourceware.org/gdb/wiki/FAQ

GDB does not see any threads besides the one in which crash occurred;
or SIGTRAP kills my program when I set a breakpoint.

    * This frequently happen on Linux, especially on embedded targets.
There are two common causes:
          o

            you are using glibc, and you have stripped libpthread.so.0
          o

            mismatch between libpthread.so.0 and libthread_db.so.1

      GDB itself does not know how to decode "thread control blocks"
maintained by glibc and considered to be glibc private implementation
detail. It uses libhread_db.so.1 (part of glibc) to help it do so.
Therefore, libthread_db.so.1 and libpthread.so.0 must match in version
and compilation flags.

      In addition, libthread_db.so.1 requires certain non-global
symbols to be present in libpthread.so.0.

      Solution: use strip --strip-debug libpthread.so.0 instead of
strip libpthread.so.0.




On Wed, May 27, 2009 at 00:02, Vellemans, Noel
<Noel.Vellemans@visionbms.com> wrote:
>
> Hi,
>
> Somebody who can point me to a document (URL) that contains some info
> about GDB-(server)debugging with threads ?
>
> I'm having problems debugging multithread applications (compiled for
> ARM).
>
>
> Ref to :  http://sourceware.org/ml/gdb/2009-05/msg00137.html
>
>
>
> GDB-6.8 (for ARM).
>
> /toolchain_build_arm/gdbhost-6.8/gdb$ ./gdb --v
> GNU gdb 6.8
> Copyright (C) 2008 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show
> copying"
> and "show warranty" for details.
> This GDB was configured as "--host=i386-pc-linux-gnu
> --target=arm-linux-uclibc".
>
>
>
>
>
>
>
>
> Kind Regards,
> Noel.
>
>
>

RE: Q: GDB - Threads

[Vellemans, Noel]

Hi, still strugling to DEBUG threads...


I ' got a hint from someone that told me. 

A) I should check if my libpthread.so.0 if it is not stripped.

And it isn't ..  

arm-linux-uclibc-nm libpthread-0.9.30.1.so 
00012cf4 a _DYNAMIC
00012dbc a _GLOBAL_OFFSET_TABLE_
         w _Jv_RegisterClasses
00012ce4 d __CTOR_END__
00012cdc d __CTOR_LIST__
00012cec d __DTOR_END__
00012ce8 d __DTOR_LIST__
0000a25c r __EH_FRAME_BEGIN__
...... < removed some stuff here >>


B) that there should be a mismatch between libthread.so.0 and libthread_db.so.1
Both libs have been build on the same system.. (buildroot).. 
Even started from scratch.... 
 88 -rw-r--r--  1 noel noel  82178 2009-06-02 16:23 libpthread-0.9.30.1.so
  0 lrwxrwxrwx  1 noel noel     22 2009-06-02 16:23 libpthread.so.0 -> libpthread-0.9.30.1.so

 16 -rw-r--r--  1 noel noel  13171 2009-06-02 16:23 libthread_db-0.9.30.1.so
  0 lrwxrwxrwx  1 noel noel     24 2009-06-02 16:23 libthread_db.so.1 -> libthread_db-0.9.30.1.so




Still not able to debug a MT-application :-( 

Anyone that can help me 'little' further ??


Ref to :  http://sourceware.org/ml/gdb/2009-05/msg00137.html



Kind regards Noel.



-----Original Message-----
From: Hui Zhu [mailto:teawater@gmail.com] 
Sent: 27May09 00:08
To: Vellemans, Noel
Cc: gdb@sourceware.org
Subject: Re: Q: GDB - Threads

http://sourceware.org/gdb/current/onlinedocs/gdb_5.html#SEC28
http://sourceware.org/gdb/wiki/FAQ

GDB does not see any threads besides the one in which crash occurred; or SIGTRAP kills my program when I set a breakpoint.

    * This frequently happen on Linux, especially on embedded targets.
There are two common causes:
          o

            you are using glibc, and you have stripped libpthread.so.0
          o

            mismatch between libpthread.so.0 and libthread_db.so.1

      GDB itself does not know how to decode "thread control blocks"
maintained by glibc and considered to be glibc private implementation detail. It uses libhread_db.so.1 (part of glibc) to help it do so.
Therefore, libthread_db.so.1 and libpthread.so.0 must match in version and compilation flags.

      In addition, libthread_db.so.1 requires certain non-global symbols to be present in libpthread.so.0.

      Solution: use strip --strip-debug libpthread.so.0 instead of strip libpthread.so.0.




On Wed, May 27, 2009 at 00:02, Vellemans, Noel <Noel.Vellemans@visionbms.com> wrote:
>
> Hi,
>
> Somebody who can point me to a document (URL) that contains some info 
> about GDB-(server)debugging with threads ?
>
> I'm having problems debugging multithread applications (compiled for 
> ARM).
>
>
> Ref to :  http://sourceware.org/ml/gdb/2009-05/msg00137.html
>
>
>
> GDB-6.8 (for ARM).
>
> /toolchain_build_arm/gdbhost-6.8/gdb$ ./gdb --v GNU gdb 6.8 Copyright 
> (C) 2008 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show 
> copying"
> and "show warranty" for details.
> This GDB was configured as "--host=i386-pc-linux-gnu 
> --target=arm-linux-uclibc".
>
>
>
>
>
>
>
>
> Kind Regards,
> Noel.
>
>
>

Re: Q: GDB - Threads

[Paul Pluzhnikov]

On Tue, Jun 2, 2009 at 8:27 AM, Vellemans, Noel
<Noel.Vellemans@visionbms.com> wrote:

> Still not able to debug a MT-application :-(
> Anyone that can help me 'little' further ??

There is (I think) a very high probability that your GDB did not load
correct libthread_db.

> Both libs have been build on the same system.. (buildroot)..
> Even started from scratch....
> 88 -rw-r--r--  1 noel noel  82178 2009-06-02 16:23 libpthread-0.9.30.1.so
> 16 -rw-r--r--  1 noel noel  13171 2009-06-02 16:23 libthread_db-0.9.30.1.so

The identical time stamp implies that these were both installed at the
same time, which means they are both built for *target*.

But you need an identical libthread_db built for *host*.

This is because GDB (on host) will try to dlopen() libthread_db (which
helps it debug *target* libpthread).

Once you build correct libthread_db, you'll likely need to adjust
LD_LIBRARY_PATH for GDB to actually find it at runtime.

To see which (if any) libthread_db GDB is loading now do this:
in a separate window execute 'grep libthread_db /proc/<pid-of-gdb>/maps'

Cheers,
-- 
Paul Pluzhnikov

Re: Q: GDB - Threads

[Daniel Jacobowitz]

On Tue, Jun 02, 2009 at 09:41:19AM -0700, Paul Pluzhnikov wrote:
> > Both libs have been build on the same system.. (buildroot)..
> > Even started from scratch....
> > 88 -rw-r--r--  1 noel noel  82178 2009-06-02 16:23 libpthread-0.9.30.1.so
> > 16 -rw-r--r--  1 noel noel  13171 2009-06-02 16:23 libthread_db-0.9.30.1.so
> 
> The identical time stamp implies that these were both installed at the
> same time, which means they are both built for *target*.
> 
> But you need an identical libthread_db built for *host*.
> 
> This is because GDB (on host) will try to dlopen() libthread_db (which
> helps it debug *target* libpthread).

I'm not sure what you mean.  GDB never uses libthread_db on the host
if it is debugging a remote target.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Q: GDB - Threads

[Paul Pluzhnikov]

On Tue, Jun 2, 2009 at 11:17 AM, Daniel Jacobowitz <drow@false.org> wrote:

> GDB never uses libthread_db on the host
> if it is debugging a remote target.

Oops. Sorry, my mistake.

I guess then OP needs to verify that GDB is loading symbols from expected
libpthread ("set verbose on" should show that), and that gdbserver on target
is loading expected libthread_db ("ldd gdbserver" on target should show
that).

-- 
Paul Pluzhnikov

Re: Q: GDB - Threads

[Daniel Jacobowitz]

On Tue, Jun 02, 2009 at 11:34:40AM -0700, Paul Pluzhnikov wrote:
> On Tue, Jun 2, 2009 at 11:17 AM, Daniel Jacobowitz <drow@false.org> wrote:
> 
> > GDB never uses libthread_db on the host
> > if it is debugging a remote target.
> 
> Oops. Sorry, my mistake.
> 
> I guess then OP needs to verify that GDB is loading symbols from expected
> libpthread ("set verbose on" should show that), and that gdbserver on target
> is loading expected libthread_db ("ldd gdbserver" on target should show
> that).

Right.  I don't remember if gdbserver's debug output helps with this
or not.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Q: GDB - Threads

[Paul Pluzhnikov]

On Tue, Jun 2, 2009 at 11:34 AM, Paul Pluzhnikov <ppluzhnikov@google.com> wrote:

> I guess then OP needs to verify that GDB is loading symbols from expected
> libpthread ("set verbose on" should show that), and that gdbserver on target
> is loading expected libthread_db ("ldd gdbserver" on target should show
> that).

Oh, and one very common mistake is to strip libpthread before it is uploaded
to target. Make sure libpthread *on target* has not been stripped. In
particular, it should have some local *_version symbol.

Cheers,
-- 
Paul Pluzhnikov

Re: Q: GDB - Threads

[Hui Zhu]

On Wed, Jun 3, 2009 at 03:42, Paul Pluzhnikov <ppluzhnikov@google.com> wrote:
> On Tue, Jun 2, 2009 at 11:34 AM, Paul Pluzhnikov <ppluzhnikov@google.com> wrote:
>
>> I guess then OP needs to verify that GDB is loading symbols from expected
>> libpthread ("set verbose on" should show that), and that gdbserver on target
>> is loading expected libthread_db ("ldd gdbserver" on target should show
>> that).
>
> Oh, and one very common mistake is to strip libpthread before it is uploaded
> to target. Make sure libpthread *on target* has not been stripped. In
> particular, it should have some local *_version symbol.
>

I remember in remote debug, libpthread striped or not is not very important.

Noel, you are use remote debug right? If so, I suggest:
1. Make sure you gdbserver in target link with libthread_db is OK.
You can check it with ldd.
2. Make sure you gdb in host use right lib.
Sometime, the host and target use different lib.  If so, you need copy
the lib in target to host, and then you can use command "set
solib-search-path" or "set sysroot" in gdb to let gdb load right lib.
And you need make sure libpthread that gdb load (in host) is not striped.

Thanks,
Hui

RE: Q: GDB - Threads

[Vellemans, Noel]

Hi,

First of all I want to thank everyone dor the responses so far....


Here it goes.....

I want to mention that I have used NO STRIPING, i.o.w strip is turned
off for all lib files (in fact for all files on the target, no striping
is used !)


On Tue, Jun 02, 2009 at 09:41:19AM -0700, Paul Pluzhnikov wrote:
> > > Both libs have been build on the same system.. (buildroot)..
> > > Even started from scratch....
> > > 88 -rw-r--r--  1 noel noel  82178 2009-06-02 16:23 
> > > libpthread-0.9.30.1.so
> > > 16 -rw-r--r--  1 noel noel  13171 2009-06-02 16:23 
> > > libthread_db-0.9.30.1.so
> > 
> > The identical time stamp implies that these were both installed at
the 
> > same time, which means they are both built for *target*.
> > 
> > But you need an identical libthread_db built for *host*.
> >



Ohhh , I think this is where it goes wrong, I was not aware of this.

NOTE: for the HOST !!
	ldd libthread_db-1.0.so 
	checking sub-depends for 'libc.so.6'
		libc.so.6 => libc.so.6 (0x00000000)
		/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00000000)

	for the TARGET
	ldd libthread_db-0.9.30.1.so 
	checking sub-depends for 'libc.so.0'
		libc.so.0 => libc.so.0 (0x00000000)
		/lib/ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x00000000)


SO this is WRONG...!!! 

The question I now have is:
My target is an ARM system (at91sam9g20), my host is a PC.
What is the CORRECT way of getting this libfile (and dependencies) the
same 'versions' on both systems!
I assume taking a 'copy' of the *target*/lib/libthread_db to
*host*/lib/libthread_db will not work (because the target is an ARM and
the host is a PC).


Some more questions remarks... (please ref to gdb verbose console log..
you might find something 'usable' in it..  )

I have set the "gdb-set solib-search-path
/buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib:/
target/lib" but gdb always find's the 
'wrong ones' (because the are in *HOST*/lib...)

After verbose mode I got this output in the gdbconsole.

warning: .dynamic section for "/lib/libpthread.so.0" is not at the
expected address (wrong library or version mismatch?)
warning: .dynamic section for "/lib/libgcc_s.so.1" is not at the
expected address (wrong library or version mismatch?)
&"warning: .dynamic section for \"/lib/libpthread.so.0\" is not at the
expected address (wrong library or version mismatch?)\n"
&"warning: .dynamic section for \"/lib/libgcc_s.so.1\" is not at the
expected address (wrong library or version mismatch?)\n"
~"Stopped due to shared library event\n"
Stopped due to shared library event
24*stopped,thread-id="1"
(gdb) 
25 info sharedlibrary
&"info sharedlibrary\n"
~"From        To          Syms Read   Shared Object Library\n"
~"0x40000930  0x40003eb0  Yes
/buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l
d-uClibc.so.0\n"
~"0x400121b0  0x4001d628  Yes         /lib/libpthread.so.0\n"   ======>
BAD ONE ! 	   <=======
~"0x40029cb0  0x40032ee8  Yes         /lib/libgcc_s.so.1\n"
======>IS  THIS IS A BAD ONE ????  <=======
~"0x40044c90  0x400855b0  Yes
/buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l
ibc.so.0\n"
25^done

At this time (for testing) I have deleted the "wrong" libfiles on my
host, to make sure GDB finds the correct ones.:-))
And now I have this output...

Stopped due to shared library event
204*stopped,thread-id="1"
(gdb) 
205 info sharedlibrary
&"info sharedlibrary\n"
~"From        To          Syms Read   Shared Object Library\n"
~"0x40000930  0x40003eb0  Yes
/buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l
d-uClibc.so.0\n"
~"0x40011cc0  0x4001820c  Yes
/buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l
ibpthread.so.0\n" ==>> OK           <==
~"0x40029ca0  0x40030ec4  Yes
/buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l
ibgcc_s.so.1\n"   ==>> ?? BETTER ?? <==
~"0x40044c90  0x400855b0  Yes
/buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l
ibc.so.0\n"
205^done


Which seems to be better ... I guess :-), but how do I fix this the
normal way (without deleting) ?



I have included the gdb console log , you guy's might see anything in it
I'm not aware



Kind regards NOEL.




<<< GBD verbose conlose log... >>>

1-gdb-set confirm off
1^done
(gdb) 
2-gdb-set width 0
2^done
(gdb) 
3-gdb-set height 0
3^done
(gdb) 
4-interpreter-exec console echo
4^done
(gdb) 
5-gdb-show prompt
5^done,value="(gdb) "
(gdb) 
6-gdb-set auto-solib-add on
6^done
(gdb) 
7-gdb-set stop-on-solib-events 0
7^done
(gdb) 
8-gdb-set stop-on-solib-events 1
8^done
(gdb) 
9-gdb-show solib-search-path
9^done,value=""
(gdb) 
10-gdb-set solib-search-path
/buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib:/
target/lib
10^done
(gdb) 
11-target-select remote 150.158.204.147:9000
~"[New Thread 912]\n"
[New Thread 912]
11^connected,thread-id="1",frame={addr="0x40000930",func="_start",args=[
],from="/buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/ro
ot/lib/ld-uClibc.so.0"}
(gdb) 
12-environment-cd /buildhome/DU7PE/software/threading
12^done
(gdb) 
13-environment-directory /buildhome/DU7PE/software/threading
/buildhome/DU7PE/software/threading/sources
13^done,source-path="/buildhome/DU7PE/software/threading:/buildhome/DU7P
E/software/threading/sources:$cdir:$cwd"
(gdb) 
14 info threads
&"info threads\n"
~"* 1 Thread 912  0x40000930 in _start () from
/buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l
d-uClibc.so.0\n"
14^done
(gdb) 
15-data-list-register-names
15^done,register-names=["r0","r1","r2","r3","r4","r5","r6","r7","r8","r9
","r10","r11","r12","sp","lr","pc","f0","f1","f2","f3","f4","f5","f6","f
7","fps","cpsr","","","","","","","","","","","","","","","","","","",""
,"","","","","","","","","","","","",""]
(gdb) 
16-stack-info-depth
16^done,depth="2"
(gdb) 
17-stack-list-frames 0 2
17^done,stack=[frame={level="0",addr="0x40000930",func="_start",from="/b
uildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/ld-
uClibc.so.0"},frame={level="1",addr="0x00000000",func="??"}]
(gdb) 
18-break-insert -t main
During symbol reading, DW_AT_name missing from DW_TAG_base_type.
&"During symbol reading, DW_AT_name missing from DW_TAG_base_type.\n"
18^done,bkpt={number="1",type="breakpoint",disp="del",enabled="y",addr="
0x00008784",func="main",file="sources/main.c",fullname="/buildhome/DU7PE
/software/threading/sources/main.c",line="46",times="0"}
(gdb) 
19-exec-continue
19^running
(gdb) 
~"Stopped due to shared library event\n"
Stopped due to shared library event
19*stopped,thread-id="1"
(gdb) 
20 info sharedlibrary
&"info sharedlibrary\n"
~"From        To          Syms Read   Shared Object Library\n"
~"0x40000930  0x40003eb0  Yes
/buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l
d-uClibc.so.0\n"
~"0x40011cc0  0x4001820c  Yes
/buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l
ibpthread.so.0\n"
~"0x40029ca0  0x40030ec4  Yes
/buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l
ibgcc_s.so.1\n"
~"0x40044c90  0x400855b0  Yes
/buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l
ibc.so.0\n"
20^done
(gdb) 
21-exec-continue
21^running
(gdb) 
~"Stopped due to shared library event\n"
Stopped due to shared library event
21*stopped,thread-id="1"
(gdb) 
22 info sharedlibrary
&"info sharedlibrary\n"
~"From        To          Syms Read   Shared Object Library\n"
~"0x40000930  0x40003eb0  Yes
/buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l
d-uClibc.so.0\n"
~"0x40011cc0  0x4001820c  Yes
/buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l
ibpthread.so.0\n"
~"0x40029ca0  0x40030ec4  Yes
/buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l
ibgcc_s.so.1\n"
~"0x40044c90  0x400855b0  Yes
/buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l
ibc.so.0\n"
22^done
(gdb) 
23-exec-continue
23^running
(gdb) 
23*stopped,thread-id="1",frame={addr="0x00008784",func="main",args=[],fi
le="sources/main.c",fullname="/buildhome/DU7PE/software/threading/source
s/main.c",line="46"}
(gdb) 
24 info threads
&"info threads\n"
&"During symbol reading, incomplete CFI data; unspecified registers
(e.g., r0) at 0x8780.\n"
~"* 1 Thread 912  main () at sources/main.c:46\n"
24^done
(gdb) 
25-stack-info-depth
25^done,depth="1"
(gdb) 
26-stack-list-frames 0 1
26^done,stack=[frame={level="0",addr="0x00008784",func="main",file="sour
ces/main.c",fullname="/buildhome/DU7PE/software/threading/sources/main.c
",line="46"}]
(gdb) 
27-data-list-changed-registers
27^done,changed-registers=["0","1","2","3","4","5","6","7","8","9","10",
"11","12","13","14","15","16","17","18","19","20","21","22","23","24","2
5"]
(gdb) 
28 info sharedlibrary
&"info sharedlibrary\n"
~"From        To          Syms Read   Shared Object Library\n"
~"0x40000930  0x40003eb0  Yes
/buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l
d-uClibc.so.0\n"
~"0x40011cc0  0x4001820c  Yes
/buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l
ibpthread.so.0\n"
~"0x40029ca0  0x40030ec4  Yes
/buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l
ibgcc_s.so.1\n"
~"0x40044c90  0x400855b0  Yes
/buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l
ibc.so.0\n"
28^done
(gdb) 
29-stack-list-arguments 0 0 0
29^done,stack-args=[frame={level="0",args=[]}]
(gdb) 
30-stack-list-locals 0
30^done,locals=[name="threads",name="rc",name="t"]
(gdb) 
31 whatis threads
&"whatis threads\n"
~"type = pthread_t [5]\n"
31^done
(gdb) 
32 ptype pthread_t [5]
&"ptype pthread_t [5]\n"
~"type = long unsigned int [5]\n"
32^done
(gdb) 
33 whatis rc
&"whatis rc\n"
~"type = int\n"
33^done
(gdb) 
34 whatis t
&"whatis t\n"
~"type = int\n"
34^done
(gdb) 
35-var-create - * threads
35^done,name="var1",numchild="5",value="[5]",type="pthread_t [5]"
(gdb) 
36-var-create - * &(threads)
36^done,name="var2",numchild="1",value="0xbec86d20",type="pthread_t
(*)[5]"
(gdb) 
37-var-set-format var2 hexadecimal
37^done,format="hexadecimal",value="0xbec86d20"
(gdb) 
38 ptype pthread_t (*)[5]
&"ptype pthread_t (*)[5]\n"
~"type = long unsigned int (*)[5]\n"
38^done
(gdb) 
39-var-evaluate-expression var2
39^done,value="0xbec86d20"
(gdb) 
40-var-create - * rc
40^done,name="var3",numchild="0",value="-1094160715",type="int"
(gdb) 
41-var-create - * t
41^done,name="var4",numchild="0",value="1074339480",type="int"
(gdb) 
42-var-evaluate-expression var3
42^done,value="-1094160715"
(gdb) 
43-var-evaluate-expression var4
43^done,value="1074339480"
(gdb) 
44-break-insert main.c:48
44^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr=
"0x000087f8",func="main",file="sources/main.c",fullname="/buildhome/DU7P
E/software/threading/sources/main.c",line="48",times="0"}
(gdb) 

RE: Q: GDB - Threads

[Vellemans, Noel]

I'm here again...

Tried all suggestions... but still not working. 

I guess I'm missing something but ..... What?
Some ideas or hints, or some places ..where to find more info ?
I've been digging in the GDB-manual and mailing list for some time
now... :-( :-( 


I'll try to give a small resume of what I'm trying to do.

*HOST : PC (ubuntu 9.04)
*TARGET : ARM (at91sam9g20)
*Buildsystem: buildroot 06/2009 - uclibc-0.9.30.1, gdb 6.8,gcc-4.3.3
*Striping : TURNED OFF. (for all files, this also means libs)
*Test-Application : a simpe applciation that uses PTHREAD's!! 
*GDB: GDB / Gdbserver 6.8 for ARM (all is built for arm-linux-uclibc- )


When the application is run in 'remote-'gdb the application 'HANGS' as
soon as the second thread is created.

(target : gdbserver *:9000 ./threading)
(host : gdb - over TCP/IP -> target ip-address port 9000)

>>> target console log <<<
# gdbserver *:9000 ./threading 
Process ./threading created; pid = 905
Listening on port 9000
Remote debugging from host 150.158.205.4
Creating thread 0

0: Hello World! 0 
Creating thread 1

0: Hello World! 1
 
--->> and now .. the target is 'HANGING' <<---------




>> a normal run on the target ARM -- gives me the expected output <<

When the Test-application runs STAND-ALONE on the target (normal
behavoir... As expected ;-))
./threading 
Creating thread 0
0: Hello World! 0 
Creating thread 1
1: Hello World! 0 
Creating thread 2
2: Hello World! 0 
Creating thread 3
3: Hello World! 0 
Creating thread 4
4: Hello World! 0 
Sleeping/printing in main ..... 
printing in main 0 
0: Hello World! 1 
1: Hello World! 1 
2: Hello World! 1 
<< some things.. Are removed here >>
 Hello World! 19 

4: Hello World! 19 
printing in main 19 
printing in main 20 
printing in main 21 
printing in main 22 
printing in main 23 
printing in main 24 
printing in main 25 
printing in main 26 
printing in main 27 
printing in main 28 
printing in main 29 
Sleeping in main ..... DONE .. 


What I do not understand is the following:
Most people (that have responded, again THANKS for all responses, and
sorry I'll keep on bothering you all, but I'm just trying to get my
DEBUGGING problem solved..) point me to the fact that my libs
(especially libthread_db) would be a wrong version..

But here it comes ... I can't see/understand why I would need
libthread_db .. I'm using pthreads !
In fact the only thing I try (at this time) is to step in the 'main' of
the program, even not in a 'p'thread.


<< please have a look at this GDB-CONSOLE-LOG  >>

/buildhome/20090601/buildroot/toolchain_build_arm/gdbhost-6.8/gdb$ ./gdb

GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show
copying"
and "show warranty" for details.
This GDB was configured as "--host=i386-pc-linux-gnu
--target=arm-linux-uclibc".
Setting up the environment for debugging gdb.
Setting up the environment for debugging gdb - DONE .
Breakpoint 1 at 0x8784: file sources/main.c, line 46.
(NOEL2-gdb) run
Starting program: /tmp/threading 
[New Thread 906]
[Switching to Thread 906]
Stopped due to shared library event
(NOEL2-gdb) c
Continuing.
Stopped due to shared library event
(NOEL2-gdb) info shared li
From        To          Syms Read   Shared Object Library
0x40000930  0x40003eb0  Yes
/buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l
d-uClibc.so.0
0x40011cc0  0x4001820c  Yes
/buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l
ibpthread.so.0
0x40029ca0  0x40030ec4  Yes
/buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l
ibgcc_s.so.1
0x40044c90  0x400855b0  Yes
/buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l
ibc.so.0
(NOEL2-gdb) info breakpoints 
Num     Type           Disp Enb Address    What
1       breakpoint     keep y   0x00008784 in main at sources/main.c:46
(NOEL2-gdb) l
37	  }
38	   pthread_exit(NULL);
39	}
40	
41	int main()
42	{
43	   pthread_t threads[NUM_THREADS];
44	   int rc, t;
45	   for(t=0;t<NUM_THREADS;t++){
46	      printf("Creating thread %d\r\n", t);
(NOEL2-gdb) l
47	      rc = pthread_create(&threads[t], NULL, PrintHello, (void
*)t);
48	      if (rc){
49	         printf("ERROR; return code from pthread_create() is
%d\r\n", rc);
50	         exit(-1);
51	      }
52	   }
53	
54	   printf("Sleeping/printing in main ..... \r\n");
55	   {
56		   int n;
(NOEL2-gdb) b main.c:48
Breakpoint 2 at 0x87f8: file sources/main.c, line 48.
(NOEL2-gdb) c
Continuing.

Breakpoint 1, main () at sources/main.c:46
46	      printf("Creating thread %d\r\n", t);
(NOEL2-gdb) info breakpoints 
Num     Type           Disp Enb Address    What
1       breakpoint     keep y   0x00008784 in main at sources/main.c:46
	breakpoint already hit 1 time
2       breakpoint     keep y   0x000087f8 in main at sources/main.c:48
(NOEL2-gdb) info shared li
From        To          Syms Read   Shared Object Library
0x40000930  0x40003eb0  Yes
/buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l
d-uClibc.so.0
0x40011cc0  0x4001820c  Yes
/buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l
ibpthread.so.0
0x40029ca0  0x40030ec4  Yes
/buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l
ibgcc_s.so.1
0x40044c90  0x400855b0  Yes
/buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l
ibc.so.0
(NOEL2-gdb) c
Continuing.

Breakpoint 2, main () at sources/main.c:48
48	      if (rc){
(NOEL2-gdb) info breakpoints 
Num     Type           Disp Enb Address    What
1       breakpoint     keep y   0x00008784 in main at sources/main.c:46
	breakpoint already hit 1 time
2       breakpoint     keep y   0x000087f8 in main at sources/main.c:48
	breakpoint already hit 1 time
(NOEL2-gdb) c
Continuing.
<< HANGING >>



I would expect the GDB-debugger to stop at main.c:48 (the break point is
still there ...) but it doesn't. (and the programs HANGS forever)!



The Target Console output I get is :
Remote debugging from host 150.158.205.4
Process /tmp/threading created; pid = 906
Creating thread 0

0: Hello World! 0 
Creating thread 1

0: Hello World! 1 

<< HANGING >>






Kind regards,


Noel.



 

-----Original Message-----
From: Daniel Jacobowitz [mailto:drow@false.org] 
Sent: 2Jun09 21:34
To: Paul Pluzhnikov
Cc: Vellemans, Noel; gdb@sourceware.org
Subject: Re: Q: GDB - Threads

On Tue, Jun 02, 2009 at 11:34:40AM -0700, Paul Pluzhnikov wrote:
> On Tue, Jun 2, 2009 at 11:17 AM, Daniel Jacobowitz <drow@false.org>
wrote:
> 
> > GDB never uses libthread_db on the host if it is debugging a remote 
> > target.
> 
> Oops. Sorry, my mistake.
> 
> I guess then OP needs to verify that GDB is loading symbols from 
> expected libpthread ("set verbose on" should show that), and that 
> gdbserver on target is loading expected libthread_db ("ldd gdbserver" 
> on target should show that).

Right.  I don't remember if gdbserver's debug output helps with this or
not.

--
Daniel Jacobowitz
CodeSourcery