Thread: [Prex-devel] Educational use?
Status: Beta
Brought to you by:
kohtani
Menu
▾
▴
prex-devel
|
From: Peter D. <pj...@cc...> - 2011-02-11 03:47:13
|
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 pj...@cc... Northeastern Computer & Information Science |
|
From: Andrew D. <and...@gm...> - 2011-02-12 00:29:57
|
On 11 February 2011 14:46, Peter Desnoyers <pj...@cc...> 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 |
|
From: Andrew D. <and...@gm...> - 2011-02-12 04:45:23
|
Replying to the list too... On 12 February 2011 14:48, Peter Desnoyers <pj...@cc...> wrote: > On 02/11/2011 07:27 PM, Andrew Dennison wrote: >> On 11 February 2011 14:46, Peter Desnoyers <pj...@cc...> 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. 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. > >> >> We haven't heard from Kohsuke for a while but I'm sure he is working >> away adding some interesting features. > > At this point I've already committed to Prex for this term, but the > development model is making me nervous. In particular, I'm worried that > any effort I put in will be wasted, or else I'll be stuck using an old > version just like you are. That is currently one of the challenges - I think it has scared off a few other users. I started maintaining a public git tree based on 0.8.1 to fill this void, but the large changes in the 0.9 tarball stalled that effort. Kohsuke mentioned setting up a public repository a few years ago and it would be fantastic if he took that step. There are a few of us who would like to contribute to Prex on a regular basis. Andrew |
|
From: Peter D. <pj...@cc...> - 2011-02-12 16:38:23
|
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 pj...@cc... Northeastern Computer & Information Science |
|
From: Andrew D. <and...@gm...> - 2011-02-12 20:11:53
|
On 13 February 2011 03:38, Peter Desnoyers <pj...@cc...> 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 |
|
From: Andrew D. <and...@gm...> - 2011-07-16 22:33:43
|
On 11 February 2011 14:46, Peter Desnoyers <pj...@cc...> wrote: > I'm using Prex in an operating systems class this term, and was > wondering if anyone else had tried this. Hi Peter, Was using Prex in your class successful? Which areas of Prex did your students work on? Andrew |
Thanks for helping keep SourceForge clean.
X