bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Debugging ghc6: Was: Re: Failure: ghc ...


From: Samuel Thibault
Subject: Re: Debugging ghc6: Was: Re: Failure: ghc ...
Date: Thu, 14 Apr 2011 15:51:55 +0200
User-agent: Mutt/1.5.12-2006-07-14

Svante Signell, le Thu 14 Apr 2011 15:44:35 +0200, a écrit :
> > Also, you
> > don't really know where to put them, so you first have to investigate
> > from the point where ghc is hung, by looking at the state of the threads
> > which are answering the RPCs from ghc.
> 
> How to do that in gdb???

As usual:

thread apply all bt

then look which one seems to be answering ghc6's request, use thread
xxx, frame, print, etc.

> > > 2) Can I set a break/watchpoint in a .h-file?
> > 
> > The whole point of inline functions is that they are inlined in several
> > places, so I doubt gdb supports it.
> 
> Some code is actually in header files, like in pipe.h:
> 
> __extern_inline error_t
> pipe_wait_writable (struct pipe *pipe, int noblock)
> {
>   size_t limit = pipe->write_limit;
>   if (pipe->flags & PIPE_BROKEN)
>     return EPIPE;
>   while (pipe_readable (pipe, 1) >= limit)
>     {
>       if (noblock)
>         return EWOULDBLOCK;
>       if (hurd_condition_wait (&pipe->pending_writes, &pipe->lock))
>         return EINTR;
>       if (pipe->flags & PIPE_BROKEN)
>         return EPIPE;
>     }
>   return 0;
> }
> 
> How to track this stuff??

As I said, since it's duplicated, saying "I want to get a break point
here" means that gdb would have to set the breakpoint at each and every
place where the code is duplicated, I doubt gdb supports it.

> > glibc.
> 
> Do I need to go into glibc source code too??

By "glibc", I meant that, yes. You most probably only need to look at
the mach  and hurd parts: mach/ , hurd/ and sysdeps/mach/

Samuel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]