headers
Peter Desnoyers | 11 Feb 2011 04:46
Favicon

Educational use?

I'm  using Prex in an operating systems class this term, and was
wondering if anyone else had tried this.

I was also wondering whether the project has gone dead, as there are
very few messages on this list since last July.

--

-- 
.....................................................................
 Peter Desnoyers                                  pjd <at> ccs.neu.edu
 Northeastern Computer & Information Science

------------------------------------------------------------------------------
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
Permalink | Reply | 1 comment |
headers
Andrew Dennison | 12 Feb 2011 01:29
Picon

Fwd: Educational use?

On 11 February 2011 14:46, Peter Desnoyers <pjd <at> ccs.neu.edu> wrote:
> I'm  using Prex in an operating systems class this term, and was
> wondering if anyone else had tried this.
>
> I was also wondering whether the project has gone dead, as there are
> very few messages on this list since last July.

This sounds like a very good use of Prex, as it has a fairly clean
structure and good abstraction of the architecture specific
components.

The Prex mailing list has always been quiet, but there seem to be a
few of us lurking and ready to join in whenever some discussion
starts.

For the most part we're been just _using_ Prex for the last 6 months
or so, it is now nice and stable so our efforts have all been focused
on our product rather than more enhancements to Prex. Unfortunately I
can't comment on Prex 0.9, as I haven't yet found the time to merge
our changes with the latest release.

We haven't heard from Kohsuke for a while but I'm sure he is working
away adding some interesting features.

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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Dennison | 12 Feb 2011 05:45
Picon

Re: Educational use?

Replying to the list too...

On 12 February 2011 14:48, Peter Desnoyers <pjd <at> ccs.neu.edu> wrote:
> On 02/11/2011 07:27 PM, Andrew Dennison wrote:
>> On 11 February 2011 14:46, Peter Desnoyers <pjd <at> ccs.neu.edu> wrote:
>>> I'm  using Prex in an operating systems class this term, and was
>>> wondering if anyone else had tried this.
>>>
>>> I was also wondering whether the project has gone dead, as there are
>>> very few messages on this list since last July.
>>
>> This sounds like a very good use of Prex, as it has a fairly clean
>> structure and good abstraction of the architecture specific
>> components.
>
> Yes, as a matter of fact my class just came up with a very good list of
> possible projects this morning.
>
> By the way, do you know if anyone has a good solution to debugging
> user-space code on MMU systems? It should be straightforward on NOMMU,
> but gdb e.g. through the QEMU stub is justifiably confused by the re-use
> of the same address space in every task. If there isn't anything, we
> have some ideas for a gdb stub that could be linked with an executable,
> and a couple of extensions to sys_debug.

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.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Peter Desnoyers | 12 Feb 2011 17:38
Favicon

Re: Educational use?

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. 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.

> I haven't played with qemu debug - I've only used qemu for some basic
> sanity checking that I haven't broken the architectures I don't have
> hardware for.

It's more useful if you're working with the PC platform. All the devices
are supported out of the box, plus there's no such thing as a JTAG port
on a PC :-)

--

-- 
.....................................................................
 Peter Desnoyers                                  pjd <at> ccs.neu.edu
 Northeastern Computer & Information Science

------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andrew Dennison | 12 Feb 2011 21:11
Picon

Re: Educational use?

On 13 February 2011 03:38, Peter Desnoyers <pjd <at> ccs.neu.edu> 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
(Continue reading)

Permalink | Reply | 0 comments |

Gmane