valgrind-users

[Valgrind-users] db attach to processes vs thread

[Andy H. <And...@au...>]

Hello,

	When I specify --db-attach with helgrind, the debugger is attached to the thread in 
question, not the its parent process. Is there a way to make it attach to the process instead?

Thanks,

	Andy

fedora9
valgrind 3.4.1

Re: [Valgrind-users] db attach to processes vs thread

[Julian S. <js...@ac...>]

> 	When I specify --db-attach with helgrind, the debugger is attached to the
> thread in question, not the its parent process. Is there a way to make it
> attach to the process instead?

Not sure I quite understand.  When you say "parent process", do you mean
"the root thread of the process" ?

J

Re: [Valgrind-users] db attach to processes vs thread

[tom f. <tf...@al...>]

Andy Howell <And...@au...> writes:
> Julian Seward wrote:
> >> 	When I specify --db-attach with helgrind, the debugger is attached to t
> he
> >> thread in question, not the its parent process. Is there a way to make it
> >> attach to the process instead?
> > 
> > Not sure I quite understand.  When you say "parent process", do you mean
> > "the root thread of the process" ?
> > 
> > J
> > 
> 
> Yes, exactly. In the debugger I only see one thread, so I can't
> inspect my other threads to see what is going on.
[snip]

Use `info threads', and `thread <num>' to switch.

-tom

Re: [Valgrind-users] db attach to processes vs thread

[Andy H. <And...@au...>]

tom fogal wrote:
> Andy Howell <And...@au...> writes:
>> Julian Seward wrote:
>>>> 	When I specify --db-attach with helgrind, the debugger is attached to t
>> he
>>>> thread in question, not the its parent process. Is there a way to make it
>>>> attach to the process instead?
>>> Not sure I quite understand.  When you say "parent process", do you mean
>>> "the root thread of the process" ?
>>>
>>> J
>>>
>> Yes, exactly. In the debugger I only see one thread, so I can't
>> inspect my other threads to see what is going on.
> [snip]
> 
> Use `info threads', and `thread <num>' to switch.
> 
> -tom
> 

Tom,

	Thats the problem, unless I call gdb via my script to set the parent pid, there are no 
threads:

(gdb) info threads
(gdb)

Looks like gdb is getting that via the '%f' parameter passed by the --db-command. That is 
set to /proc/PID/fd/FILE_DESCRIPTOR

where FILE_DESCRIPTOR is the descriptor for the binary. Since my script is redirecting gdb 
to use the parent pid of the thread in question, I need to find a way to work out the 
proper descriptor.

I tried to force gdb to read the symbols from the binary with:

symbol-file BINARY_NAME -readnow

But that didn't help.

Once I figure out how to grab the symbol table, I should be fine.

Thanks,

	Andy

Re: [Valgrind-users] db attach to processes vs thread

[Andy H. <And...@au...>]

Julian Seward wrote:
>> 	When I specify --db-attach with helgrind, the debugger is attached to the
>> thread in question, not the its parent process. Is there a way to make it
>> attach to the process instead?
> 
> Not sure I quite understand.  When you say "parent process", do you mean
> "the root thread of the process" ?
> 
> J
> 

Julian,

	Yes, exactly. In the debugger I only see one thread, so I can't inspect my other threads 
to see what is going on. I made a script to query /proc and figure out the parent and 
launch gdb:

#!/bin/sh

file=$1;
pid=$2;

if [ -f /proc/${pid}/status ]; then
  ppid=`grep 'PPid:' /proc/${pid}/status|sed -e 's/PPid:[^0-9]*//'`
  echo "pid $pid ppid $ppid file $file"
  /usr/bin/gdb $file $ppid
else
  echo "can't find tgid for $pid"
  exit 1;
fi

I pass this to valgrind as:

--db-command=/home/andy/script/vg_gdb %f %p

I see all the threads, but gdb can't find the symbol tables. I have worked out how to find 
them.

Thanks,

	Andy

Re: [Valgrind-users] db attach to processes vs thread

[Julian S. <js...@ac...>]

> > Yes, exactly. In the debugger I only see one thread, so I can't
> > inspect my other threads to see what is going on.
>
> [snip]
>
> Use `info threads', and `thread <num>' to switch.

Am not 100% sure, but,

I suspect that won't work.  There's some deeply nasty magic involved,
in which we have to copy the register state of the simulated CPU into
the real CPU registers, before starting GDB.  If that isn't done, then
GDB (correctly) shows the stacks etc as being inside Valgrind itself
and not inside the program that was running on Valgrind.

So (if memory serves right), that's only done for the current thread
and not for all of them.  So I imagine that switching threads will
yield stack tracebacks inside V's code, or in code generated by the
JIT.

J

Re: [Valgrind-users] db attach to processes vs thread

[Andy H. <And...@au...>]

Julian Seward wrote:
>>> Yes, exactly. In the debugger I only see one thread, so I can't
>>> inspect my other threads to see what is going on.
>> [snip]
>>
>> Use `info threads', and `thread <num>' to switch.
> 
> Am not 100% sure, but,
> 
> I suspect that won't work.  There's some deeply nasty magic involved,
> in which we have to copy the register state of the simulated CPU into
> the real CPU registers, before starting GDB.  If that isn't done, then
> GDB (correctly) shows the stacks etc as being inside Valgrind itself
> and not inside the program that was running on Valgrind.
> 
> So (if memory serves right), that's only done for the current thread
> and not for all of them.  So I imagine that switching threads will
> yield stack tracebacks inside V's code, or in code generated by the
> JIT.

Julian,

	That would explain why my attempts to load the symbol table manually failed. Looks like 
its not going to work without more magic.

Thanks,

	Andy