Re: [Sbcl-devel] Re: SBCL on FreeBSD

[Raymond W. <ra...@or...>]

William Harold Newman writes:
 > On Tue, Feb 29, 2000 at 09:06:11AM +0100, Raymond Wiker wrote:
 > > William Harold Newman writes:
 > >  > On Mon, Feb 28, 2000 at 04:22:42PM +0100, Raymond Wiker wrote:
 > >  > > 	I'm having trouble debugging this, as gdb does not appear to
 > >  > > work with breakpoints in code called from lisp. I.e, once the runtime
 > >  > > has made the transfer to lisp, my breakpoints will not be
 > >  > > honoured. I'll see if a more recent version of gdb works better.
 > >  > 
 > >  > My impression was that this happens because the Lisp system wants to
 > >  > handle all signals itself, and one of the signals it takes over is the
 > >  > one which gdb uses for its breakpoints. My guess is that if you want
 > >  > to be able to set gdb breakpoints in a running SBCL, it might be more
 > >  > fruitful not to look for a newer gdb but instead to cook up some way
 > >  > to suppress the way SBCL munges this particular signal. Perhaps it
 > >  > could be controlled with an --under-gdb option from the command line
 > >  > or something.

	It took quite some time before I understood what you meant
here... as I said, I had no problems setting breakpoints, but that was
before sbcl got so far as to take over the signals (SIGABRT in
particular). 

 > > 	I got a little bit further last night - turns out that there
 > > were a couple more instances in the lisp code where an underscore was
 > > prepended to foreign symbols. I had also left out undefineds.c from
 > > the compilation, which accounted for 31 of the 32 cases of "undefined
 > > foreign symbol" that I noticed (the last was update_errno, which seems
 > > to be specific to Linux/glibc2).
 > 
 > It'd probably be be good to move this discussion to the sbcl-devel mailing
 > list, since about a week ago I had a discussion with Daniel Barlow
 > and Peter Van Eynde about issues with update_errno.
 > 
 > If I understood correctly, some hack like that is needed with the
 > new libc because errno has become a macro instead of an ordinary
 > variable, in order to make it thread-safe. Daniel Barlow was looking
 > for opinions about how to handle errno in his sockets interface.
 > So if you're running into porting problems with it, it might
 > be good to have everyone in on the discussion.

	The same trick seems to be necessary in FreeBSD, which defines
errno as a macro that calls a function via a pointer (huh?). It might
be better to simply have a function that retrieves the current value
of errno from the C runtime, rather than first calling a function to
update the value, and then retrieving the value.

	I've gotten a bit further, again: I switched on the sb-show
feature in target-features.lisp-expr, and that pinpointed a problem
with os-cold-init-or-reinit, which is only defined for linux. I
"fixed" this by conditionalising the call to os-cold-init-or-reinit
with #!+linux - is this right?

	At the moment I get as far as the first call to gc, which
crashes because an object (the first?) has a type tag of 0xbe (190),
which is unknown to gencgc.c (via sbcl.h). The highest type tag in use
seems to be scavenger_hook, which is 0xba (186).

	Is it possible that the :freebsd feature enables an additional
type that is somehow not picked up by the code in genesis.lisp?
(Either because it's placed in a different package or because it
breaks with the "protocol" for primitive types.) I'll check this,
anyhow.

 > [So I've sent this reply back via sbc...@li....]

	Noted - the wider audience is the reason that I've provided
more details than you need :-) 

	//Raymond.