How can I debug Squeak plugin at both C side (or the .dll perhaps), and the Smalltalk side?
Thanks. Ang Beepeng |
Well if you are using a macintosh it's easy, just follow the
instructions to build an xcode based vm, the open up the xcode project for the plugin, ensure the debug version of the plugin is findable by the debug vm put breakpoints in the vm or plugin, invoke debug. You can also configure the xcode plugin project to run a vm if needbe and not need to compile a debug vm. On 3-Mar-09, at 9:56 AM, Ang Beepeng wrote: > > How can I debug Squeak plugin at both C side (or the .dll perhaps), > and the > Smalltalk side? > > Thanks. > > Ang Beepeng > -- > View this message in context: http://www.nabble.com/debugging-plugin-and-virtual-machine-tp22314144p22314144.html > Sent from the Squeak - Dev mailing list archive at Nabble.com. > > -- = = = ======================================================================== John M. McIntosh <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== |
Thank you so much. I'm actually working on Windows base plugin.
|
2009/3/3 Ang Beepeng <[hidden email]>:
> > Thank you so much. I'm actually working on Windows base plugin. > ohh.. then i feel sorry for you :) Debugging VM on windows is a complete hell. I know it by myself, because developing Hydra VM on windows. All gbd versions which i found, can't show me a correct stack trace for VM built using gcc 2.95. :(( So i got to use 2 debuggers at once: - gdb to look for a source code at specific instruction address - visual c debugger to see the correct stack frames and function addresses.. horrible, inconvenient & takes a lot of time to find a bug... > > > John M McIntosh wrote: >> >> Well if you are using a macintosh it's easy, just follow the >> instructions to build an xcode based vm, >> the open up the xcode project for the plugin, ensure the debug version >> of the plugin is findable by the debug vm >> put breakpoints in the vm or plugin, invoke debug. >> >> You can also configure the xcode plugin project to run a vm if needbe >> and not need to compile a debug vm. >> >> = >> = >> = >> ======================================================================== >> John M. McIntosh <[hidden email]> >> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >> = >> = >> = >> ======================================================================== >> >> >> >> >> >> > > -- > View this message in context: http://www.nabble.com/debugging-plugin-and-virtual-machine-tp22314144p22315313.html > - Show quoted text - > Sent from the Squeak - Dev mailing list archive at Nabble.com. > > > -- Best regards, Igor Stasenko AKA sig. |
Thanks. So is gdb and visual studio basically. I'm looking at both it also, I was hoping to get an easier solution or at least a more direct one. Is there any documentation out there on how to debug a Windows base plugin or some sort? Thank you so much. :) Ang Beepeng |
2009/3/3 Ang Beepeng <[hidden email]>:
> > > Igor Stasenko wrote: >> >> 2009/3/3 Ang Beepeng <[hidden email]>: >>> >>> Thank you so much. I'm actually working on Windows base plugin. >>> >> >> ohh.. then i feel sorry for you :) >> Debugging VM on windows is a complete hell. >> I know it by myself, because developing Hydra VM on windows. >> >> All gbd versions which i found, can't show me a correct stack trace >> for VM built using gcc 2.95. :(( >> So i got to use 2 debuggers at once: >> - gdb to look for a source code at specific instruction address >> >> - visual c debugger to see the correct stack frames and function >> addresses.. >> horrible, inconvenient & takes a lot of time to find a bug... >> >> Best regards, >> Igor Stasenko AKA sig. >> >> >> > > Thanks. > > So is gdb and visual studio basically. I'm looking at both it also, I was > hoping to get an easier solution or at least a more direct one. > > Is there any documentation out there on how to debug a Windows base plugin > or some sort? > not winMain()..) I able to debug things in PHP-like style: self cCode:'dprintf("here")'. .... some code.. self cCode:'dprintf("there")'. this helps me to locate the troublemaking code. :) I tried to find a debugger with UI, which understands a GNU debug info in windows, but failed. I don't know how GNU guys explaing the limitation of having a command-line debugger in 21st century.. Sometimes this is the only option (like for embedded devices - but even then you'd better use remote debugger), but almost always its not. Try search for it, maybe things changed... and if you find it, let me know. I need it as well! :) > Thank you so much. :) > > Ang Beepeng > > -- > View this message in context: http://www.nabble.com/debugging-plugin-and-virtual-machine-tp22314144p22316397.html > - Show quoted text - > Sent from the Squeak - Dev mailing list archive at Nabble.com. > > > -- Best regards, Igor Stasenko AKA sig. |
Hi-- Since no-cost versions of Visual Studio C++ became available, I've adapted the VM build environment for it. I've got a big demo at work this week, but next week I can put it somewhere and help people work out the kinks. Oh, and I hasten to point out that my primary machine is not a Windoze box. :) -C -- Craig Latta www.netjam.org next show: 2009-03-13 (www.thishere.org) |
Could be useful to any brave souls who want to help WxSqueak move onward!
I think Rob [Gayvert] had the whole thing compiling with VC++ 6.0, which I never had... Rob Rothwell On Wed, Mar 4, 2009 at 1:41 AM, Craig Latta <[hidden email]> wrote:
|
In reply to this post by ccrraaiigg
2009/3/4 Craig Latta <[hidden email]>:
> > Hi-- > > Since no-cost versions of Visual Studio C++ became available, I've > adapted the VM build environment for it. I've got a big demo at work this > week, but next week I can put it somewhere and help people work out the > kinks. > > Oh, and I hasten to point out that my primary machine is not a Windoze > box. :) > This is why i abandoned idea with building VM with GCC 4.xxx , because its 30% or more slower than compiled by 2.95. > > -C > > -- > Craig Latta > www.netjam.org > next show: 2009-03-13 (www.thishere.org) > > > > -- Best regards, Igor Stasenko AKA sig. |
In reply to this post by ccrraaiigg
Hi.
I wish to know more about developing Squeak VM with Visual Studio. How can I get the source of the VS version of Squeak VM? Thanks. Ang Beepeng
|
Hi Ang,
On Mon, Jul 13, 2009 at 12:13 AM, Ang Beepeng <[hidden email]> wrote:
There is no special version. One needs makefiles that work with VisualStudio. Craig Latta has some. I have some. Alas these are not used often enough to be guaranteed to work. We're about to release the Cog Stack Interpreter, an interim VM on the way to the full JIT. This will include my makefiles. If you can wait a few weeks take them from there.
best Eliot
|
Hi.
Can I know what is the development environment used for Cog? How it is debugged? Thank you so much for your reply. Ang Beepeng
|
On Tue, Jul 14, 2009 at 5:05 AM, Ang Beepeng <[hidden email]> wrote:
On Mac OS X I use XCode to build, using either the included gcc or the intel icc compiler. The intel compiler makes a lot of difference for the interpreter Ms but little difference for cog. But since I've been using icc for the interpreter it is more work to switch back :) For debugging I use gdb.
On Windows I use cygwin to build with the 3.4.x compiler, but we can also build with the older 2.95 mingw environment, and with Visual C++ of any vintage from 6 onwards. To debug I typically use cygwin with gdb. For some reason the newer MinGW 5.1.4 with the gcc 3.4.5 compiler doesn't work yet.
On linux I use whatever the bundled gcc is so that currently means gcc 4.1.x & gdb 6.x. And of course I do as much debugging and development in Squeak as possible :)
|
Administrator
|
Thanks for the info for developing Cog. Are you using Slang to write the VM? Are you using something like InterpreterSimulator too? Is Cog still written in Smalltalk, converted to C and compiled into an executable?
Thanks, Aik-Siong Koh |
On Tue, Jul 14, 2009 at 1:38 PM, askoh <[hidden email]> wrote:
Yes. Are you using something like InterpreterSimulator too? Yes. Except that the generated x86 machine code is executed by a virtual processor packaged as an external plugin built using the Bochs x86 PC simulator written in C++. The generated machine code is written into the same large ByteArray that houses the Smalltalk heap.
There are also a lot more classes involved cogmethod.h: CogBlockMethod/CogMethod - objects representing the headers of machine code methods cointerp.c ObjectMemory/NewObjectMemory/StackInterpreter/CoInterpreter - the interpreter and garbage collector hierarchy
CoInterpreterStackPages & CogSimpleStackPage - where stack frames live cogit.c Cogit/SimpleStackBasedCogit - the code generator hierarchy CogObjectRepresentation/CogObjectRepresentationForSqueakV3 - the abstraction of object access so one can plug-in object representations
AbstractInstruction/CogIA32Compiler - the back-end hierarchy CogMethodZone - where generated methods live CogBlockStart, CogBytecodeDescriptor, CogBytecodeFixup, CogInstructionAnnotation, CogPrimitiveDescriptor - internal compiler data structures
CogRTLOpcodes - a pool of abstract 2-operand opcodes a few of which have simulation subclasses. So its only a bit like InterpreterSimulator. I expect also to abstract out the garbage collector later this year so that the interpreter has the ObjectMemory as an instance variable so one can plug-in GC & object representation.
Is Cog still written Yes.
|
Free forum by Nabble | Edit this page |