Using #stdOut from the image would not be useful for debugging a primitive or an FFI callout. Either use a real debugger (gdb et al) or put the fprintf someplace where you can see the parameters exactly as passed to the function.
Dave On Mon, Jul 12, 2010 at 10:35:36AM -0400, Schwab,Wilhelm K wrote: > Dave, > > Any thoughts on mixing fprint()/fflush() in the .so with #stdOut in the > image? I found #helloWorld, but some tinkering suggests that it is very > sensitive to using #lf vs. #cr and/or does not like #flush. Does any of that > sound familiar? > > Bill > > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of David T. > Lewis > Sent: Monday, July 12, 2010 5:32 AM > To: Squeak Virtual Machine Development Discussion > Cc: [email protected] > Subject: Re: [Pharo-project] [Vm-dev] Tracing on Linux > > On Sun, Jul 11, 2010 at 05:30:35PM -0400, Schwab,Wilhelm K wrote: > > > > I am trying to track down a segmentation fault in calling into the Gnu > > Scientific Library. These are things that I had working under > > Windows+Dolphin and am now trying to do with Pharo and Linux. Offsets to > > structure elements and sizes of structures are possible snags, but the > > calls that are failing should be reasonably independent of such things: I > > call the relevant allocation method and pass along the pointer, so even if > > my interpretation of the structs is bogus, I would still expect the > > functions to succeed. That is all the more true of new functions that I am > > adding for testing purposes. > > > > The GSL functionality is split into two libraries, and the .so modules > > appear to be hobbled on Linux due to circular dependencies between them. A > > wrapper .so that is linked to both libraries seems to allow me to call > > "all" of the functions (the few I have tried to access) and gives a home > > for code of my own. > > > > I went so far as to compile some GSL sample code, and it does not crash. I > > further linked it to my wrapper library and it still works calling the GSL > > functions through the wrapper (or at least I *think* that's happening). I > > plan to gradually sneak up on the crash by moving things into my library > > and then hopefully into Pharo via FFI. > > > > On Windows, I would use OutputDebugString() to write tracing messages to > > look at what is happening until I found the problem. How do you unix VM > > gurus tackle such debugging problems? > > > > Bill, > > To write strings to output, use fprintf() followed by fflush(). > Don't forget the fflush or you'll never figure anything out ;) > > To use a debugger, compile with CFLAGS=-g (enable debugging info, no compiler > optimization), then run the VM under gdb or one of the gui front ends to gdb > such as ddd. Put a breakpoint in your function, and you're good to go. > > Assuming you are using up to date sources from Subversion, run > "platforms/unix/configure --help" for more build options. > > Dave > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
