On 13 February 2011 03:38, Peter Desnoyers <[email protected]> wrote:
> On 2/11/2011 11:45 PM, Andrew Dennison wrote:
>
>> Normally you would maintain a debug context for each process, and swap
>> the debug context as part of the task switch - the OS needs to
>> cooperate in this exercise. I've done this for some simple debug
>> support using the hardware debug support in our target processor: I'll
>> setup a gdb stub one day.
>
> What I'm not sure about is how to get gdb to take advantage of that,
> especially e.g. via the QEMU debug stub.

There is one way to you can work around this - link the task(s) you
want to debug at a different virtual address. This way you can use
QEMU debug without modification: as long as the virtual address spaces
do not overlap. Of course this means an alternate link script for each
task you want to debug, but that is fairly simple to do with some make
file tweaking.

> On the other hand, I can easily
> see how to create a couple of debug operations to allow one thread to
> get/set another's registers, and to single-step a thread; given this it
> should be straightforward to add a thread to a process which implements
> the gdb remote protocol.

You could manipulate another threads context by hacking its stack, but
a more generic solution might be to add a GDB stub to the kernel as
you have access to the appropriate data structures from there. An
earlier version of Prex (0.4.2?) had a gdb stub for i386 in the kernel
but it was only really for kernel debug, it didn't hook in the context
switch.

Andrew

------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Prex-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/prex-devel

Reply via email to