[Openmcl-devel] Problem with gtk2 on Linux/PPC

[rm at fabula.de]

On Wed, Apr 13, 2005 at 11:54:18AM -0600, Gary Byers wrote:
> 
> 
> On Wed, 13 Apr 2005 rm at fabula.de wrote:
> 
> > Hello list,
> >
> > I'm still trying to get the gtk2 bindings to work on
> > Linux/PPC. I thought that upgrading to 14.2-bleeding might
> > solve my problem (Lisp drops me into the kernel debugger
> > as soon as a callback is invoked). Well, i don't get into
> > the debugger any more - the system just exits ...
> >
> > Any ideas on how i can debug this? I tried to attach gdb
> > to the running image but this doesn't really work since
> > gdb constantly breaks on all sorts of signals.
> 
> This doesn't address the problem exactly (I'll try to respond to your
> later message soon), but you can get GDB to be a -bit- quieter when
> debugging OpenMCL by getting it to load (or "source", as a verb)
> the file ccl/lisp-kernel/PLATFORM/.gdbinint.

Thanks - i did find this gem by myself. It does help debugging.
I didn't dive into the "recompile my kernel"  or "fix gdb" - but 
i did have a look at the corefile.

> One Linux, there's still an issue having to do with what Unix
> signals are generated by PPC trap instructions.  OpenMCL code
> contains sequences like:
> 
>   (twlllt allocptr,allocbase) ; trap if this thread needs more room to
> 			      ; cons in
> 
> That generates a SIGTRAP signal; GDB mistakenly believes that all
> SIGTRAP signals must have something to do with its breakpoints, and
> gets confused when it starts to learn that this isn't the case.  There
> may be a way of patching GDB to eliminate this confusion; it's often
> simpler to patch the bit of the Linux kernel that maps PPC exceptions
> to Unix signals to generate some other signal (SIGILL) in this case.
> 
> (There are some other Linux-specific issues on recent Linux versions;
> that would be an even longer, further off-topic message.)

Too bad - might be really interesting. I learn a lot reading your posts.

> I'll try to look at gtk2 under Linux in a bit.

The strange thing is: everything seems to work fine with gtk1.n. That 
toolkit changed a lot, and some of the stuff they did adds a lot of
complication too it. There seems to be some signal marshaling going
on in the glib stuff (which now contains signaling objects). Admittedly
this makes the whole framework very generic, but still, much harder
to understand from within a debugger.

 Thanks a lot 

   RalfD

> >
> >  Thanks Ralf Mattes
> > _______________________________________________
> > Openmcl-devel mailing list
> > Openmcl-devel at clozure.com
> > http://clozure.com/mailman/listinfo/openmcl-devel
> >
> >