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
------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
