pthreads debug with gdbserver

pthreads debug with gdbserver

[Vladimir Vorobyov]

Hi,

Im using gbd 6.2 + gdbserver for m68k target and able to debug programs with 
it. But when I tried to debug application with pthreads I could not get 
correct threads information.
During debbuging I receive a well known SIG32 but searching this mail list I 
did not find the solution for my problem.
What I did:
******************************************************************************************
[root@Vlad]# ./m68k-linux-gdb
GNU gdb 6.2
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=m68k-linux".
(gdb) file /tftpboot/Linux_BSP2/rootfsdir/bin/hello
Reading symbols from 
/opt/Embedix/home/vladimir/project/rootfsdir/bin/hello...done.
(gdb) maintenance info breakpoints
Num Type           Disp Enb Address    What
-1  longjmp resume keep n   0x00000000
(gdb) set solib-absolute-prefix /tftpboot/Linux_BSP2/rootfsdir/
(gdb) target remote 192.168.1.27:3000
Remote debugging using 192.168.1.27:3000
0x400020c0 in ?? ()
(gdb) maintenance info breakpoints
Num Type           Disp Enb Address    What
-1  longjmp resume keep n   0x00000000
-2  shlib events   keep y   0x4000dd04
(gdb) c
Continuing.

Program received signal SIG32, Real-time event 32.
0x400a8b2e in ?? ()
(gdb) maintenance info breakpoints
Num Type           Disp Enb Address    What
-1  longjmp resume keep n   0x00000000
-2  shlib events   keep y   0x4000dd04
        breakpoint already hit 3 times
***************************************************************************************************
I see that shlib breakpoint is set and hit but gdb does not load the 
libraries. I can see in strace that it successfully loads ld.so. What should 
I look at?
Next, what libthread_db.so is for? It was not included for compilation for 
m68k target and I added it manually but when I try to load all libraries 
manually using add-symbol-file, every library loads fine except 
libthread_db.so - gdbserver reports "gbd: error initializing thread_db 
library."
If I type in gdb:
	info threads
I always get only one thread.
p.s. All libraries are not stripped.


Any help would be very appreciated.

Re: pthreads debug with gdbserver

[Daniel Jacobowitz]

On Fri, Nov 19, 2004 at 12:33:22PM +0200, Vladimir Vorobyov wrote:
> I see that shlib breakpoint is set and hit but gdb does not load the 
> libraries. I can see in strace that it successfully loads ld.so. What should 
> I look at?

"info shared".  Maybe strace GDB to see what it's opening and whether
it fails to find any files.

> Next, what libthread_db.so is for? It was not included for compilation for 
> m68k target and I added it manually but when I try to load all libraries 
> manually using add-symbol-file, every library loads fine except 
> libthread_db.so - gdbserver reports "gbd: error initializing thread_db 
> library."
> If I type in gdb:
> 	info threads
> I always get only one thread.
> p.s. All libraries are not stripped.

libthread_db.so is necessary to debug threads.  It has to be on your
target (sounds like it is) and it has to be able to initialize; worry
about this after you've figured out whether GDB loaded shared
libraries, because it will not be able to initialize unless GDB can
load an unstripped copy of libpthread.so.

-- 
Daniel Jacobowitz

Re: pthreads debug with gdbserver

[Vladimir Vorobyov]

On Friday 19 November 2004 04:22 pm, Daniel Jacobowitz wrote:
> On Fri, Nov 19, 2004 at 12:33:22PM +0200, Vladimir Vorobyov wrote:
> > I see that shlib breakpoint is set and hit but gdb does not load the
> > libraries. I can see in strace that it successfully loads ld.so. What
> > should I look at?

> "info shared".  Maybe strace GDB to see what it's opening and whether
> it fails to find any files.

info shared reports: "No shared libraries loaded at this time".
Straces shows that gdb opens only ld.so file.
When adding printf to solibopen it also shows only ld.so.
Who is responsible for loading shared libs ? What file/function/event?

> > Next, what libthread_db.so is for? It was not included for compilation
> > for m68k target and I added it manually but when I try to load all
> > libraries manually using add-symbol-file, every library loads fine except
> > libthread_db.so - gdbserver reports "gbd: error initializing thread_db
> > library."
> > If I type in gdb:
> > 	info threads
> > I always get only one thread.
> > p.s. All libraries are not stripped.
>
> libthread_db.so is necessary to debug threads.  It has to be on your
> target (sounds like it is) and it has to be able to initialize; worry
> about this after you've figured out whether GDB loaded shared
> libraries, because it will not be able to initialize unless GDB can
> load an unstripped copy of libpthread.so.

Yes, the problem number one is that GDB does not auto loads shared libs.
Is it not the same when I manually add-symbol-file lipthread.so? Can I do it 
to load shared libs ?
When I do this I got "gbd: error initializing thread_db library." error on the 
target. When I add debug info to it, I see that error is "Incompatible 
versions of libpthread and libthread_db". But these two libs are from the 
same libc.
It looks like this is my second problem. Or it depends on first one and may 
disappear when first problem is solved?


Regards,
Vladimir.

Re: pthreads debug with gdbserver

[Daniel Jacobowitz]

On Fri, Nov 19, 2004 at 04:41:15PM +0200, Vladimir Vorobyov wrote:
> On Friday 19 November 2004 04:22 pm, Daniel Jacobowitz wrote:
> > On Fri, Nov 19, 2004 at 12:33:22PM +0200, Vladimir Vorobyov wrote:
> > > I see that shlib breakpoint is set and hit but gdb does not load the
> > > libraries. I can see in strace that it successfully loads ld.so. What
> > > should I look at?
> 
> > "info shared".  Maybe strace GDB to see what it's opening and whether
> > it fails to find any files.
> 
> info shared reports: "No shared libraries loaded at this time".
> Straces shows that gdb opens only ld.so file.
> When adding printf to solibopen it also shows only ld.so.
> Who is responsible for loading shared libs ? What file/function/event?

This usually means that the ld.so GDB has opened is not -exactly- the
same as the one on your target; and then it has set the solib event
breakpoint at the wrong location, and it hasn't been hit.  Take a look
at solib-svr4.c if you want more details.

> Yes, the problem number one is that GDB does not auto loads shared libs.
> Is it not the same when I manually add-symbol-file lipthread.so? Can I do it 
> to load shared libs ?
> When I do this I got "gbd: error initializing thread_db library." error on the 
> target. When I add debug info to it, I see that error is "Incompatible 
> versions of libpthread and libthread_db". But these two libs are from the 
> same libc.
> It looks like this is my second problem. Or it depends on first one and may 
> disappear when first problem is solved?

Are you sure you loaded the right copy?

-- 
Daniel Jacobowitz

Re: pthreads debug with gdbserver

[Vladimir Vorobyov]

Thank for your inputs. I moved further - see below.

> > info shared reports: "No shared libraries loaded at this time".
> > Straces shows that gdb opens only ld.so file.
> > When adding printf to solibopen it also shows only ld.so.
> > Who is responsible for loading shared libs ? What file/function/event?
>
> This usually means that the ld.so GDB has opened is not -exactly- the
> same as the one on your target; and then it has set the solib event
> breakpoint at the wrong location, and it hasn't been hit.  Take a look
> at solib-svr4.c if you want more details.

As I said in my first message the breakpoint is hit exactly 3 times. I found 
that current_sos in solib-svr4.c can not find any libraries. It was because 
first_link_map_member returned NULL. After this I found that 
SVR4_FETCH_LINK_MAP_OFFSETS did not return correct offsets (which are correct 
for me? ilp32?). I tried to follow those gdbach_data calls but it was too 
difficult. I just assigned svr4_ilp32_fetch_link_map_offsets to 
SVR4_FETCH_LINK_MAP_OFFSETS (how to do it correctly?).
After this with every shlib breakpoint hit gdb loads appropriate shared lib 
BUT gdbserver reports "Target does not support breakpoints" 3 times for each 
library loaded. What does it mean ? 
I still receive SIG32, info threads still shows only one thread. "info shared" 
shows all libraries that are loaded and td_ta_new() call now returns 
successfully.

> > Yes, the problem number one is that GDB does not auto loads shared libs.
> > Is it not the same when I manually add-symbol-file lipthread.so? Can I do
> > it to load shared libs ?
> > When I do this I got "gbd: error initializing thread_db library." error
> > on the target. When I add debug info to it, I see that error is
> > "Incompatible versions of libpthread and libthread_db". But these two
> > libs are from the same libc.
> > It looks like this is my second problem. Or it depends on first one and
> > may disappear when first problem is solved?
>
> Are you sure you loaded the right copy?

Absolutely.

Regards,
Vladimir.

Re: pthreads debug with gdbserver

[Daniel Jacobowitz]

On Sat, Nov 20, 2004 at 02:27:13PM +0200, Vladimir Vorobyov wrote:
> Thank for your inputs. I moved further - see below.
> 
> > > info shared reports: "No shared libraries loaded at this time".
> > > Straces shows that gdb opens only ld.so file.
> > > When adding printf to solibopen it also shows only ld.so.
> > > Who is responsible for loading shared libs ? What file/function/event?
> >
> > This usually means that the ld.so GDB has opened is not -exactly- the
> > same as the one on your target; and then it has set the solib event
> > breakpoint at the wrong location, and it hasn't been hit.  Take a look
> > at solib-svr4.c if you want more details.
> 
> As I said in my first message the breakpoint is hit exactly 3 times. I found 
> that current_sos in solib-svr4.c can not find any libraries. It was because 
> first_link_map_member returned NULL. After this I found that 
> SVR4_FETCH_LINK_MAP_OFFSETS did not return correct offsets (which are correct 
> for me? ilp32?). I tried to follow those gdbach_data calls but it was too 
> difficult. I just assigned svr4_ilp32_fetch_link_map_offsets to 
> SVR4_FETCH_LINK_MAP_OFFSETS (how to do it correctly?).
> After this with every shlib breakpoint hit gdb loads appropriate shared lib 
> BUT gdbserver reports "Target does not support breakpoints" 3 times for each 
> library loaded. What does it mean ? 
> I still receive SIG32, info threads still shows only one thread. "info shared" 
> shows all libraries that are loaded and td_ta_new() call now returns 
> successfully.

Take a look at the source code to gdbserver.  Andreas, now I remember
why I enabled thread_db support on a per-target basis - there are other
support routines that have to be written.

-- 
Daniel Jacobowitz

Re: pthreads debug with gdbserver

[Andreas Schwab]

Daniel Jacobowitz <drow@false.org> writes:

> Take a look at the source code to gdbserver.  Andreas, now I remember
> why I enabled thread_db support on a per-target basis - there are other
> support routines that have to be written.

Yes, I have noticed that, too.  I'm currently trying to get it working for
m68k (plus support for PTRACE_GETREGS).

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: pthreads debug with gdbserver

[Vladimir Vorobyov]

> > As I said in my first message the breakpoint is hit exactly 3 times. I
found
> > that current_sos in solib-svr4.c can not find any libraries. It was
because
> > first_link_map_member returned NULL. After this I found that
> > SVR4_FETCH_LINK_MAP_OFFSETS did not return correct offsets (which are
correct
> > for me? ilp32?). I tried to follow those gdbach_data calls but it was
too
> > difficult. I just assigned svr4_ilp32_fetch_link_map_offsets to
> > SVR4_FETCH_LINK_MAP_OFFSETS (how to do it correctly?).
> > After this with every shlib breakpoint hit gdb loads appropriate shared
lib
> > BUT gdbserver reports "Target does not support breakpoints" 3 times for
each
> > library loaded. What does it mean ?
> > I still receive SIG32, info threads still shows only one thread. "info
shared"
> > shows all libraries that are loaded and td_ta_new() call now returns
> > successfully.
>
> Take a look at the source code to gdbserver.  Andreas, now I remember
> why I enabled thread_db support on a per-target basis - there are other
> support routines that have to be written.

> Yes, I have noticed that, too.  I'm currently trying to get it working for
> m68k (plus support for PTRACE_GETREGS).


What routines should I add?

Also I've added set_solib_svr4_fetch_link_map_offsets (gdbarch,
svr4_ilp32_fetch_link_map_offsets) to m68klinux-tdep.c.
It fixed the problem with bad link_map_offsets.

Regards,
Vladimir.

NPTL on ppc (was: pthreads debug with gdbserver)

[Linh Dang]

Daniel Jacobowitz <drow@false.org> wrote:
>
> Take a look at the source code to gdbserver.  Andreas, now I
> remember why I enabled thread_db support on a per-target basis -
> there are other support routines that have to be written.

Hi Daniel and Andreas,

Does gdbserver works with NPTL on ppc32? I use 6.3.50 and I keep
getting on the target side:

        gdbserver 47.129.74.85:8888 p_greetings2
        Process p_greetings2 created; pid = 288
        Listening on port 8888
        Remote debugging from host 47.129.74.85
        error = 0
        error = 0
        Cannot find new threads: generic error
        error = 0
        Cannot find new threads: generic error
        error = 0
        Cannot find new threads: generic error


and on the host side:

        target extended-remote 47.135.196.213:8888
        Remote debugging using 47.135.196.213:8888
        0x30011e28 in ?? ()
        (gdb) b main
        Breakpoint 1 at 0x1000080c
        (gdb) info b
        Num Type           Disp Enb Address    What
        1   breakpoint     keep y   0x1000080c <main+28>
        (gdb) c
        Continuing.
        Ignoring packet error, continuing...
        Ignoring packet error, continuing...
        Ignoring packet error, continuing...

        Breakpoint 1, 0x1000080c in main ()
        (gdb) info shared
        From        To          Syms Read   Shared Object Library
        0x0ffd17e4  0x0ffdbd4c  Yes         /linux-tools-2.6/powerpc-linux/lib/libpthread.so.0
        0x0fe9b060  0x0ff850a4  Yes         /linux-tools-2.6/powerpc-linux/lib/libc.so.6
        0x30001ee0  0x300155d0  Yes         /linux-tools-2.6/powerpc-linux/lib/ld.so.1
        (gdb)


Thanx
-- 
Linh Dang

Re: NPTL on ppc (was: pthreads debug with gdbserver)

[Daniel Jacobowitz]

On Mon, Dec 06, 2004 at 01:22:26PM -0500, Linh Dang wrote:
> 
> Daniel Jacobowitz <drow@false.org> wrote:
> >
> > Take a look at the source code to gdbserver.  Andreas, now I
> > remember why I enabled thread_db support on a per-target basis -
> > there are other support routines that have to be written.
> 
> Hi Daniel and Andreas,
> 
> Does gdbserver works with NPTL on ppc32? I use 6.3.50 and I keep
> getting on the target side:

6.3.50 indicates some snapshot.  It depends on when the snapshot was
taken; can you give us the full version info?

I believe it should work.

-- 
Daniel Jacobowitz

Re: NPTL on ppc

[Linh Dang]

(gdb) show version
GNU gdb 6.3.50_20041027
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=powerpc-linux".


I got the same failure with any official version (6.2, 6.1.1, etc.)


Regards
-- 
Linh Dang

Re: NPTL on ppc

[Daniel Jacobowitz]

On Mon, Dec 06, 2004 at 02:56:19PM -0500, Linh Dang wrote:
> 
> 
> (gdb) show version
> GNU gdb 6.3.50_20041027
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "--host=i686-pc-linux-gnu --target=powerpc-linux".
> 
> 
> I got the same failure with any official version (6.2, 6.1.1, etc.)

Is your gdbserver also of that version?  They should match.

If so, I'm out of ideas; you will have to debug it yourself.

-- 
Daniel Jacobowitz

Re: NPTL on ppc

[Andreas Schwab]

Daniel Jacobowitz <drow@false.org> writes:

> If so, I'm out of ideas; you will have to debug it yourself.

It may be a bug in glibc/libthread_db, td_ta_thr_iter is returning an
error.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: NPTL on ppc

[Andreas Schwab]

Daniel Jacobowitz <drow@false.org> writes:

> If so, I'm out of ideas; you will have to debug it yourself.

NPTL debugging requires a functional implementation of ps_lgetregs, but
gdbserver on ppc does not implement it.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: NPTL on ppc

[Linh Dang]

Andreas Schwab <schwab@suse.de> wrote:

> Daniel Jacobowitz <drow@false.org> writes:
>
>> If so, I'm out of ideas; you will have to debug it yourself.
>
> NPTL debugging requires a functional implementation of ps_lgetregs,
> but gdbserver on ppc does not implement it.

dummy question:

ptrace(2) on linux-ppc doesn't support PTRACE_GETREGS, how does gdb
get registers from the inferior process? (the native gdb works fine
with NPTL, just gdbserver that has trouble.)


Thanx
--
Linh Dang

Re: NPTL on ppc

[Andreas Schwab]

"Linh Dang" <linhd@nortelnetworks.com> writes:

> ptrace(2) on linux-ppc doesn't support PTRACE_GETREGS, how does gdb
> get registers from the inferior process?

Using PTRACE_PEEKUSR and PTRACE_GETVRREGS and PTRACE_GETEVRREGS.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: NPTL on ppc

[Andreas Schwab]

Linh Dang <linhd@nortelnetworks.com> writes:

> (gdb) show version
> GNU gdb 6.3.50_20041027
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "--host=i686-pc-linux-gnu --target=powerpc-linux".
>
>
> I got the same failure with any official version (6.2, 6.1.1, etc.)

I see the same problem with current CVS.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: pthreads debug with gdbserver

[Vladimir Vorobyov]

> > As I said in my first message the breakpoint is hit exactly 3 times. I
found
> > that current_sos in solib-svr4.c can not find any libraries. It was
because
> > first_link_map_member returned NULL. After this I found that
> > SVR4_FETCH_LINK_MAP_OFFSETS did not return correct offsets (which are
correct
> > for me? ilp32?). I tried to follow those gdbach_data calls but it was
too
> > difficult. I just assigned svr4_ilp32_fetch_link_map_offsets to
> > SVR4_FETCH_LINK_MAP_OFFSETS (how to do it correctly?).
> > After this with every shlib breakpoint hit gdb loads appropriate shared
lib
> > BUT gdbserver reports "Target does not support breakpoints" 3 times for
each
> > library loaded. What does it mean ?
> > I still receive SIG32, info threads still shows only one thread. "info
shared"
> > shows all libraries that are loaded and td_ta_new() call now returns
> > successfully.
>
> Take a look at the source code to gdbserver.  Andreas, now I remember
> why I enabled thread_db support on a per-target basis - there are other
> support routines that have to be written.

> Yes, I have noticed that, too.  I'm currently trying to get it working for
> m68k (plus support for PTRACE_GETREGS).


> What routines should I add?

> Also I've added set_solib_svr4_fetch_link_map_offsets (gdbarch,
> svr4_ilp32_fetch_link_map_offsets) to m68klinux-tdep.c.
> It fixed the problem with bad link_map_offsets.

I think I've added all missing routines and it ALMOST work.
First, I have to specify 'set remotetimeout 60' otherwise gdb reports timeout 
error (Ignoring packet error, continuing...).
- Is it normal ?
Second, after I set any break point (e.g. break main) I cant use 'continue' 
command. Program stops after any instruction with SIGTRAP. When I force 
gdbserver to ignore 'stepping' variable, everything works fine. But Im sure 
it is wrong correction. Who is responsible for reseting stepping? And why we 
need it?

Thanks in advance.

Regards,
Vladimir.

Re: pthreads debug with gdbserver

[Daniel Jacobowitz]

On Mon, Nov 22, 2004 at 02:40:21PM +0200, Vladimir Vorobyov wrote:
> I think I've added all missing routines and it ALMOST work. First, I
> have to specify 'set remotetimeout 60' otherwise gdb reports timeout
> error (Ignoring packet error, continuing...).
> - Is it normal ?
> Second, after I set any break point (e.g. break main) I cant use 'continue' 
> command. Program stops after any instruction with SIGTRAP. When I force 
> gdbserver to ignore 'stepping' variable, everything works fine. But Im sure 
> it is wrong correction. Who is responsible for reseting stepping? And why we 
> need it?

Try CVS; Andreas has also just implemented m68k support.

-- 
Daniel Jacobowitz

Re: pthreads debug with gdbserver

[Vladimir Vorobyov]

On Monday 22 November 2004 04:06 pm, Daniel Jacobowitz wrote:
> On Mon, Nov 22, 2004 at 02:40:21PM +0200, Vladimir Vorobyov wrote:
> > I think I've added all missing routines and it ALMOST work. First, I
> > have to specify 'set remotetimeout 60' otherwise gdb reports timeout
> > error (Ignoring packet error, continuing...).
> > - Is it normal ?
> > Second, after I set any break point (e.g. break main) I cant use
> > 'continue' command. Program stops after any instruction with SIGTRAP.
> > When I force gdbserver to ignore 'stepping' variable, everything works
> > fine. But Im sure it is wrong correction. Who is responsible for reseting
> > stepping? And why we need it?
>
> Try CVS; Andreas has also just implemented m68k support.

I've downloaded the CVS version and have some questions:
1) When I try to debug following example:
*************************************************************************************
3       #define NUM_THREADS 5
4
5       void *thread_function(void *arg)
6       {
7           printf("Hello World from %d!\n", arg);
8           sleep(10);
9           printf("Exited %d!\n", arg);
10          pthread_exit(NULL);
11      }
12
13      int main (int argc, char *argv[])
14      {
15          pthread_t threads[NUM_THREADS];
16          int i;
17
18          for (i = 0; i < NUM_THREADS; i++)
19          {
20              pthread_create(&threads[i], NULL, thread_function, (void *)i);
21              printf("Thread %d created.\n", i);
22          }
23          for (i = 0; i < NUM_THREADS; i++)
24              pthread_join(threads[i], NULL);
25
26          printf("finish!\n");
27          return (0);
28      }
******************************************************************************************
I put first break point to line 23. When program stops, 'info threads' shows:
(gdb) info threads
  7 Thread 81926  0x40126f56 in nanosleep ()
   from /tftpboot/rootfsdir/lib/libc.so.6
  6 Thread 65541  0x40126f56 in nanosleep ()
   from /tftpboot/rootfsdir/lib/libc.so.6
  5 Thread 49156  0x40126f56 in nanosleep ()
   from /tftpboot/rootfsdir/lib/libc.so.6
  4 Thread 32771  0x40126f56 in nanosleep ()
   from /tftpboot/rootfsdir/lib/libc.so.6
  3 Thread 16386  0x40126f56 in nanosleep ()
   from /tftpboot/rootfsdir/lib/libc.so.6
  2 Thread 32769  0x40150a0e in loser_poll ()
   from /tftpboot/rootfsdir/lib/libc.so.6
* 1 Thread 16384  main (argc=1, argv=0xbffffe04) at hello.c:23

Looks perfectly for me.
After this if I set "break 9 thread 3" and "continue", program stops on 
correct line but I can't 'step' it:

(gdb) c
Continuing.
[Switching to Thread 16386]

Breakpoint 4, thread_function (arg=0x0) at hello.c:9
9           printf("Exited from %d!\n", arg);
(gdb) step

Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 32771]
0x80000540 in thread_function (arg=0x1) at hello.c:9
9           printf("Exited from %d!\n", arg);
(gdb) c
Continuing.

Program received signal SIGILL, Illegal instruction.
0x80000540 in thread_function (arg=0x1) at hello.c:9
9           printf("Exited from %d!\n", arg);
(gdb) x /20i $pc
0x80000540 <thread_function+36>:        010
0x80000542 <thread_function+38>:        pea 0x800006d4 <_IO_stdin_used+26>
0x80000548 <thread_function+44>:        bsrl 0x80000414 <printf>
0x8000054e <thread_function+50>:        addql #8,%sp
0x80000550 <thread_function+52>:        clrl %sp@-
0x80000552 <thread_function+54>:        bsrl 0x80000444 <pthread_exit>
0x80000558 <thread_function+60>:        nop
0x8000055a <main>:      linkw %fp,#-24
0x8000055e <main+4>:    clrl %fp@(-24)
......
Andreas, do you have this problem on your side?

2) I still need 'set remotetimeout 30' because otherwise I get error "Ignoring 
packet error, continuing...". What can gdbserver do for 30 seconds?

Sorry for the long post.
Could you recommend anything?

Regards,
Vladimir.

Re: pthreads debug with gdbserver

[Andreas Schwab]

Vladimir Vorobyov <vladimir.vorobyov@iss.org.ua> writes:

> Next, what libthread_db.so is for? It was not included for compilation for 
> m68k target and I added it manually

What do you mean with "not included for compilation"?

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: pthreads debug with gdbserver

[Vladimir Vorobyov]

On Friday 19 November 2004 05:53 pm, Andreas Schwab wrote:
> Vladimir Vorobyov <vladimir.vorobyov@iss.org.ua> writes:
> > Next, what libthread_db.so is for? It was not included for compilation
> > for m68k target and I added it manually
>
> What do you mean with "not included for compilation"?
>
> Andreas.

Sorry for my English.
I mean that this file (thread_db.c) was not compiled when I was building 
gdbserver for m68k-linux-gcc target, and gdbserver was not linked with 
libthread_db.
I've added "srv_linux_thread_db=yes" to "m68*-*-linux*" section of 
configure.srv file. Is it correct?

Re: pthreads debug with gdbserver

[Andreas Schwab]

Vladimir Vorobyov <vladimir.vorobyov@iss.org.ua> writes:

> I've added "srv_linux_thread_db=yes" to "m68*-*-linux*" section of 
> configure.srv file. Is it correct?

I think so.  Actually I don't understand why it is actually not enabled
for _all_ linux targets, since it's a generic part of glibc.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: pthreads debug with gdbserver

[Daniel Jacobowitz]

On Fri, Nov 19, 2004 at 06:05:04PM +0100, Andreas Schwab wrote:
> Vladimir Vorobyov <vladimir.vorobyov@iss.org.ua> writes:
> 
> > I've added "srv_linux_thread_db=yes" to "m68*-*-linux*" section of 
> > configure.srv file. Is it correct?
> 
> I think so.  Actually I don't understand why it is actually not enabled
> for _all_ linux targets, since it's a generic part of glibc.

'cuz it never occured to me to do it that way.  If you would like to
fix this, please go ahead.

-- 
Daniel Jacobowitz