[Vm-dev] patch: fix build problems on Solaris
ag at computer.org
Thu Sep 27 19:54:21 UTC 2007
Hi VM people,
I apologise in advance for the length of this post.
On 9/27/07, Andreas Wacknitz <A.Wacknitz at gmx.de> wrote:
> This patch fixes 4 problems which prevented the VM from building
> on Solaris/SPARC. They shouldn't cause problems for other
> Interesting that there is another guy running Squeak under Solaris.
Yeah. I have an Intel Linux PC at work and a Sun SPARC at home.
How times have changed!
Which version of the VM sources you are talking about?
> I have 3.9-8 running for quite some time on my Blade 2000.
> Although I haven't used sound yet.
This is the Subversion sources that I'm building, rev 1762.
I have good experiences with Sun's CoolTools gcc for SPARC systems.
> This is a gcc-4.0.4 frontend with a SunStudio 12 code generator.
> The code runs at least twice as fast as with a plain gcc-3.4.3.
Cool. That's good to know.
With this patch, the VM builds and runs fine if built with gcc-3.4.3.
> I've checked both the stock 3.9a-7024 image as well as the
> etoys image. (My motivation for this whole exercise is to fix the
> problems with audio under Solaris for my young daughter to use
> etoys: the first sound plays, but after that, no sounds ever play.)
> With gcc-4.2.1 and -O2, the VM won't even start up (complains
> about a missing vm-display-X11, even though it's there). With
> gcc-4.2.1 and no -O2, the VM starts, runs for a short while, and
> then cores with a bus error. gdb shows a corrupt stack. I'm
> about to build gcc-4.1.2 and give it a spin building the VM to
> try to track this down. But I do suspect bad code generation
> with gcc-4.2.1.
I take back what I said about gcc-4.2.1. I'm pretty sure that this was
due to user-stupidity (mine).
Did you manage to build libffi-2.0? This library is part of gcc-4.2.1.
AFAIK it is necessary for Squeak's FFI. I have only an old libffi-1.2.0 that
> has some Solaris bugs. So I don't have FFI which is needed for some
> packages (e.g. ODBC).
Hmm. I haven't tried building libffi. That might be my next project,
once this is sorted out. Anyway, on to the sound problems.
Thanks to the patch by *Wolfgang Helbig* at
the problem was quite simple to fix. I made a few small changes,
and sound is working on Solaris/SPARC hardware natively (no NAS
needed). Note that it looks like vm-sound-sun never implemented
recording; this is playback only (which is fine for my purposes).
According to the squeak porting guide, to make sounds, the snd_Start
C function is called. This is passed a (Squeak/smalltalk) semaphore
"that should be signalled when input/output completes". I take it this
means that the sound driver should signal the semaphore when the
sound device has space for writing.
(An old copy of the Squeak porting guide is here:
I have a much newer version on paper, but I can't remember where
I got it.)
When I send a sound, it plays fine, but when I signal the semaphore
that output has completed, the VM keeps writing more and more stuff to
the sound device. I assume that it's writing "silence", since I hear
nothing after the initial sound. But it does keep the CPU quite busy
as you might imagine.
I have instrumented the C code where the VM checks for I/O (aioPoll),
and under ordinary usage (keyboard, mouse, etc.) I get under 20
polls/second. As soon as a sound has started playing, this jumps
to 2300+ polls/second, and stays there, even when the sound is
played and silence reigns.
I can't figure out why it would do this.
Clearly, since the buffer is large enough to contain only a fraction
of a second of audio data, the semaphore is needed to tell the VM
to send some more data. And clearly the select() call in aioPoll will
notice the file-descriptor for /dev/audio is writable as soon as the
first sample is played, and continuously thereafter, so I can
understand that during playback the poll-rate should be high. This
problem should be fix-able by using the STREAMS SIGPOLL to
trigger the auHandle() function, rather than using select().
However, once the whole sound is played, why would the VM
continue playing nothing at full speed? Even with the SIGPOLL
handler in place -- I'm about to try it now -- the VM is still issuing
write() calls to /dev/audio several time per second, indefinitely.
I'm sure I'm missing something here...
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev