Three weeks ago I was trying to find a crash in Agent. Since I don't know the code of wine so well I tried to do this with a debugger. My experience was rather frustrating. GDB and winegdb are not exactly what I call userfriendly. On a Windows system I would have found this error within a few hours but I didn't come to terms with winedbg and gdb. So I was looking for an alternative and I found a project on sourceforge named pICE. This project was abandoned about two years ago, but I was interested in it and now I got the administration for it. pICE is a kernel debugger for linux similar to SoftICE and I thought it would be nice to have such a tool. My intention is to add extensions to support wine debugging as well (this was my primary reason) and now I would like to know if this is would be of interest to you as well and if yes (what I hope :) ) what extensions are needed in order to support wine. I guess that winedbg is similar in that respect that it is also an extension of gdb, am I right? If somebody knows the details I would like to hear it. But don't expect anything soon because I still need to dig into the code of pICE to make it stable first.
Look in the ReactOS source tree. Eugene Ingerman ported PICE to ReactOS for us about a year ago.
Thanks Steven
--- "Gerhard W. Gruber" sparhawk@gmx.at wrote:
Three weeks ago I was trying to find a crash in Agent. Since I don't know the code of wine so well I tried to do this with a debugger. My experience was rather frustrating. GDB and winegdb are not exactly what I call userfriendly. On a Windows system I would have found this error within a few hours but I didn't come to terms with winedbg and gdb. So I was looking for an alternative and I found a project on sourceforge named pICE. This project was abandoned about two years ago, but I was interested in it and now I got the administration for it. pICE is a kernel debugger for linux similar to SoftICE and I thought it would be nice to have such a tool. My intention is to add extensions to support wine debugging as well (this was my primary reason) and now I would like to know if this is would be of interest to you as well and if yes (what I hope :) ) what extensions are needed in order to support wine. I guess that winedbg is similar in that respect that it is also an extension of gdb, am I right? If somebody knows the details I would like to hear it. But don't expect anything soon because I still need to dig into the code of pICE to make it stable first.
-- Gerhard Gruber
F�r jedes menschliche Problem gibt es immer eine einfache L�sung: Klar, einleuchtend und falsch. (Henry Louis Mencken)
__________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com
On Thu, 12 Jun 2003 08:54:21 -0700 (PDT), Steven Edwards steven_ed4153@yahoo.com wrote:
Look in the ReactOS source tree. Eugene Ingerman ported PICE to ReactOS for us about a year ago.
Where can I find this?
I was looking for references to pICE but I found none. The only reference that I found is Klaus Gerlichers homepage and sourceforge but bith are quite outdated.
You will need to access the reactos cvs at mok.lvcm.com our CVS is moving soon to osexperts.com but for the time being you can get the needed information from www.reactos.com.
Here is the CVS web view http://mok.lvcm.com/cgi-bin/reactos/ros-cvs/reactos/apps/utils/pice/
Thanks Steven
--- "Gerhard W. Gruber" sparhawk@gmx.at wrote:
On Thu, 12 Jun 2003 08:54:21 -0700 (PDT), Steven Edwards steven_ed4153@yahoo.com wrote:
Look in the ReactOS source tree. Eugene Ingerman ported PICE to ReactOS for us about a year
ago.
Where can I find this?
I was looking for references to pICE but I found none. The only reference that I found is Klaus Gerlichers homepage and sourceforge but bith are quite outdated.
-- Gerhard Gruber
F�r jedes menschliche Problem gibt es immer eine einfache L�sung: Klar, einleuchtend und falsch. (Henry Louis Mencken)
__________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com
On Thu, 12 Jun 2003 11:42:57 -0700 (PDT), Steven Edwards steven_ed4153@yahoo.com wrote:
You will need to access the reactos cvs at mok.lvcm.com our CVS is moving soon to osexperts.com but for the time being you can get the needed information from www.reactos.com.
Here is the CVS web view http://mok.lvcm.com/cgi-bin/reactos/ros-cvs/reactos/apps/utils/pice/
Thanks. Looks interesting. If I read this right then ReactOS is a complete replacement for NT? Not running under Linux but it's own OS?
Quite some task but really interesting. :)
Gerhard W. Gruber wrote:
Three weeks ago I was trying to find a crash in Agent. Since I don't know the code of wine so well I tried to do this with a debugger. My experience was rather frustrating. GDB and winegdb are not exactly what I call userfriendly. On a Windows system I would have found this error within a few hours but I didn't come to terms with winedbg and gdb. So I was looking for an alternative and I found a project on sourceforge named pICE.
what didn't you like in gdb and winedbg ? trying to port pice to wine would be rather an heavy task I don't really what you will gain with pICE
This project was abandoned about two years ago, but I was interested in it and now I got the administration for it. pICE is a kernel debugger for linux similar to SoftICE and I thought it would be nice to have such a tool. My intention is to add extensions to support wine debugging as well (this was my primary reason) and now I would like to know if this is would be of interest to you as well
I personnaly don't see an interest. It's already a burden to maintain winedbg, so maintaining a second debugger doesn't seem right to me
and if yes (what I hope :) ) what extensions are needed in order to support wine.
ROS port uses a specific device driver, which will be fun to implement in wine
I guess that winedbg is similar in that respect that it is also an extension of gdb, am I right?
winedbg has been inspired by gdb, but it is not an extension of gdb (as a standalone debugger). But, you're may be talking of the proxy feature of winedbg which lets gdb talk to wine thru gdb's remote protocol
If somebody knows the details I would like to hear it. But don't expect anything soon because I still need to dig into the code of pICE to make it stable first.
Again, I don't see what pICE will bring you that you don't have in gdb or winedbg. IMO, you should start by explaining this.
A+
On Thu, 12 Jun 2003 18:51:52 +0200, Eric Pouech pouech-eric@wanadoo.fr wrote:
what didn't you like in gdb and winedbg ?
The interface is quite annyoing. A lot to type again and again. In pICE I have all the relevant information at one glance. I was also thinking of adding user space support, so that you can use pICE also as a normal debugger with a user space GUI. I think there may be already some support for such a feature but I didn't have time to look at all the code. Also I didn't manage to get hardware breakpoints to work and I got no response on my question about this.
trying to port pice to wine would be rather an heavy task
I haven't thought it an easy task either. :) But this is something that might interest me. Also I wasn't thinking of actually porting pICE to wine. Rather I thought, if this is possible of course, to write something like a plug-in mechanism, where wine could be supported through. I don't know if this is possible or how much work this is yet. the advantage of such a system could be to provide a debugger that may support other projects as well (like bochs). Bochs is just an example. I know that they have some debugger support, but I don't know how good it is and what it can do and what not.
I don't really what you will gain with pICE
A much better user interface and also a more powerfull debugger (I assume) than gdb is. I know that gdb is quite good and I work with it also but I don't really like it. From the pointer of usabillity I think that i.E. Visual Studio is much nicer and also SoftICE has a much better user interface. I can still see the advantages of gdb's user interface so this is not an issue.
I personnaly don't see an interest. It's already a burden to maintain winedbg, so maintaining a second debugger doesn't seem right to me
You wouldn't have to maintain it because it is a seperate project. I was just feeling out if there is interest (personally I have it) and what would be needed in order to achieve this.
ROS port uses a specific device driver, which will be fun to implement in wine
Could you tell me a bit more about this?
winedbg has been inspired by gdb, but it is not an extension of gdb (as a standalone debugger). But, you're may be talking of the proxy feature of winedbg which lets gdb talk to wine thru gdb's remote protocol
Ah. Because of this I thought that winedbg would be a frontend like wdb. Only that it is no GUI frontend but a code frontend.
Again, I don't see what pICE will bring you that you don't have in gdb or winedbg. IMO, you should start by explaining this.
I hope that I answered this. :)
Gerhard W. Gruber wrote:
On Thu, 12 Jun 2003 18:51:52 +0200, Eric Pouech pouech-eric@wanadoo.fr wrote:
what didn't you like in gdb and winedbg ?
The interface is quite annyoing. A lot to type again and again. In pICE I have all the relevant information at one glance. I was also thinking of adding user space support, so that you can use pICE also as a normal debugger with a user space GUI. I think there may be already some support for such a feature but I didn't have time to look at all the code.
try ddd (or kgdb)
Also I didn't manage to get hardware breakpoints to work and I got no response on my question about this.
what was the issue ?
ROS port uses a specific device driver, which will be fun to implement in wine
Could you tell me a bit more about this?
it seems that pice in ros needs a specific device driver, I assume it : 1/ implements low level CPU management (ie fault detection...) 2/ implements some kind of terminal emulation (screen shall be shared between debugger and debuggee) (including screen & keyboard) which I think will be hard to implement (with pice current architecture)
winedbg has been inspired by gdb, but it is not an extension of gdb (as a standalone debugger). But, you're may be talking of the proxy feature of winedbg which lets gdb talk to wine thru gdb's remote protocol
Ah. Because of this I thought that winedbg would be a frontend like wdb. Only that it is no GUI frontend but a code frontend.
that's why you can use any graphical frontend to gdb (which will then talk to wine thru winedbg) and gain every feature at once
A+
-
Eric Pouech -
Gerhard W. Gruber -
Steven Edwards