[OpenSmalltalk/opensmalltalk-vm] Solaris (#479)

 

Attempt to create a pull request for GIT branch "solaris" to COG.

---

You can view, comment on, or merge this pull request online at:

  https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/479

Commit Summary

• Solaris fixes. Add build.sunos32x86
• Add build.sunosamd64 for 64bit on Solaris
• Add Solaris IPS manifest.
• Change docdir from /usr/doc to /usr/share/doc. Set version to 5.3.1
• Update IPS manifest for version 5.3.1. Include doc/LICENSE.gz file.
• Compilation SunPro sqUnixITimerHeartbeat
• Use FASYNC on __sun__ instead of FIOASYNC
• Put back VM_VERSION to 5.0
• IPS manifest used for squeak5@5.3.1
• Define MIX / MAX so that vm-sound-pulse.so loads.
• make vm-sound-pulse the default
• Compile on Solaris with --disable-dynamicopenssl
• Compile on Solaris with --disable-dynamicopenssl
• Include opensslv to define OPENSSL_VERSION_NUMBER

File Changes

• A build.sunos32x86/HowToBuild (119)
• A build.sunos32x86/squeak.cog.spur/build/mvm (40)
• A build.sunos32x86/squeak.cog.spur/plugins.ext (16)
• A build.sunos32x86/squeak.cog.spur/plugins.int (38)
• A build.sunosamd64/HowToBuild (145)
• A build.sunosamd64/squeak.cog.spur/build.itimerheartbeat/mvm (32)
• A build.sunosamd64/squeak.cog.spur/build/mvm (39)
• A build.sunosamd64/squeak.cog.spur/plugins.ext (16)
• A build.sunosamd64/squeak.cog.spur/plugins.int (38)
• A build.sunosamd64/squeak.cog.spur/squeak5.p5m (34)
• A build.sunosamd64/squeak.cog.spur/squeak5.p5m.res (4)
• M platforms/Cross/plugins/IA32ABI/ia32abicc.c (4)
• M platforms/Cross/plugins/IA32ABI/x64sysvabicc.c (2)
• M platforms/Cross/vm/sqAtomicOps.h (7)
• M platforms/Cross/vm/sqMemoryFence.h (2)
• M platforms/unix/config/make.cfg.in (2)
• M platforms/unix/plugins/SqueakSSL/openssl_overlay.h (5)
• M platforms/unix/plugins/SqueakSSL/sqUnixOpenSSL.inc (9)
• M platforms/unix/vm-sound-pulse/sqUnixSoundPulseAudio.c (7)
• M platforms/unix/vm/aio.c (1)
• M platforms/unix/vm/include_ucontext.h (4)
• M platforms/unix/vm/sqUnixExternalPrims.c (8)
• M platforms/unix/vm/sqUnixHeartbeat.c (4)
• M platforms/unix/vm/sqUnixITimerHeartbeat.c (4)
• M platforms/unix/vm/sqUnixMain.c (5)
• M scripts/checkSCCSversion (2)

Patch Links:

• https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/479.patch
• https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/479.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

<script type="application/ld+json">[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/479", "url": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/479", "name": "View Pull Request" }, "description": "View this Pull Request on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]</script>

 

@cstes pushed 1 commit.

• 25b1a9e Remove -g debug flag for 32bit build

—
You are receiving this because you are subscribed to this thread.
View it on GitHub or unsubscribe.

<script type="application/ld+json">[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/479/files/498058994987ab62620cbd97938a77c6609d67f8..25b1a9e511ad873f9b1f427811f88d0b1424cb9b", "url": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/479/files/498058994987ab62620cbd97938a77c6609d67f8..25b1a9e511ad873f9b1f427811f88d0b1424cb9b", "name": "View Pull Request" }, "description": "View this Pull Request on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]</script>

 

would it be possible to name the 64-bit folder sunos64x64 for consistency with the other folders?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

<script type="application/ld+json">[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/479#issuecomment-609372456", "url": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/479#issuecomment-609372456", "name": "View Pull Request" }, "description": "View this Pull Request on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]</script>

 

Well yes, I could rename the folder to sunos64x64, no problem.

By the way the interesting thing is that I've meanwhile discovered why my
32bit 5.0 vm ("cog spur") felt strange and was not doing fast redraws (I
reported that it had "screen update" issues, but that is solved now).

Because I copied a "mvm" script and modified it, it had a -g flag, and the
-g compilation flag had major impact, it seems, in my case (which in many C
programs is not the case, but for my vm apparently it did).

The "cog spur" vm 32 bit is also working fine on Solaris when I compile it
without -g.

What I'll do, is to cancel the "pull request" and try a new one after I
rename the folder.

Also I'm going to undo the commit that made "vm-sound-pulse" the default.  
This is for me on Solaris working nice, I prefer the "vm-sound-pulse" module
for pulseaudio sound, but I shouldn't have made it the default on all
platforms ...

Let me submit then after this, a new pull request ...



--
Sent from: http://forum.world.st/Squeak-VM-f104410.html

 

Closed #479.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

<script type="application/ld+json">[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/479#event-3201915781", "url": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/479#event-3201915781", "name": "View Pull Request" }, "description": "View this Pull Request on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]</script>

 

Attempt to stop git pull request.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

<script type="application/ld+json">[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/479#issuecomment-609389975", "url": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/479#issuecomment-609389975", "name": "View Pull Request" }, "description": "View this Pull Request on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]</script>

 
On 05/04/20 3:16 PM, stes wrote:
> Also I'm going to undo the commit that made "vm-sound-pulse" the default.
> This is for me on Solaris working nice, I prefer the "vm-sound-pulse" module
> for pulseaudio sound, but I shouldn't have made it the default on all
> platforms ...

Please make it a default for all Unix/Linux platforms, but propose it in
a separate pull request. Thanks.

It is about time we made pulse audio module by default for all
Unix/Linux platforms. The current default, OSS, hasn't been part of
Linux kernel for a long time now.

Regards .. Subbu

 
On 05/04/20 3:16 PM, stes wrote:
> Because I copied a "mvm" script and modified it, it had a -g flag, and the
> -g compilation flag had major impact, it seems, in my case (which in many C
> programs is not the case, but for my vm apparently it did).

You could create two separate build directories

    build/mvm for production VM compiled with -O flag
    build.debug/mvm for debug VM compiled with -g flag

Regards .. Subbu

 

I started by copying the "mvm" script from linux:

build.linux32x86/squeak.cog.spur/build
OPT="-g -O2 -DNDEBUG -DDEBUGVM=0"

build.linux32x86/squeak.cog.spur/build.debug
OPT="-g3 -O0 -DDEBUGVM=1"

Note that in my case I seem to have a more responsive VM when I remove the
-g flag.  And indeed, if debugging is required I'll add a build.debug
directory for the solaris tree (with the -g enabled in that directory).

Currently I also only have looked at the "squeak cog spur" tree, while there
are various other build trees for other types of VM's in there,   that I
still have to learn about ...




--
Sent from: http://forum.world.st/Squeak-VM-f104410.html

 
On Sun, Apr 05, 2020 at 05:52:13PM +0530, K K Subbu wrote:
+1

Dave

 
On 05/04/20 6:14 PM, stes wrote:
> build.linux32x86/squeak.cog.spur/build
> OPT="-g -O2 -DNDEBUG -DDEBUGVM=0"

Production builds should be using -O and not "-g -Ox" option. I don't
know why the -g flag was turned on for production builds. It is probably
a left over from an experiment.

On Solaris, you could try using -O in place of -O2 and let the compiler
choose the best optimization level. The level should be overridden only
when the default level triggers a defect in the compiler.

Eliot, I just discovered that the 5.x releases were compiled this way.
Is this an oversight or a deliberate choice?

HTH .. Subbu

 
Hi Subbu

> On 06.04.2020, at 06:04, K K Subbu <[hidden email]> wrote:
>
> On 05/04/20 6:14 PM, stes wrote:
>> build.linux32x86/squeak.cog.spur/build
>> OPT="-g -O2 -DNDEBUG -DDEBUGVM=0"
>
> Production builds should be using -O and not "-g -Ox" option.


Why? Really.
It rather depends on the compiler, no?
With gcc and clang, -g+-O is actually a good idea, especially if you use "external" debug symbols like dwarf directories...

Best regards
        -Tobias

> I don't know why the -g flag was turned on for production builds. It is probably a left over from an experiment.
>
> On Solaris, you could try using -O in place of -O2 and let the compiler choose the best optimization level. The level should be overridden only when the default level triggers a defect in the compiler.
>
> Eliot, I just discovered that the 5.x releases were compiled this way. Is this an oversight or a deliberate choice?
>
> HTH .. Subbu

 
On 06/04/20 10:24 AM, Tobias Pape wrote:
>> Production builds should be using -O and not "-g -Ox" option.
>
> Why? Really. It rather depends on the compiler, no? With gcc and
> clang, -g+-O is actually a good idea, especially if you use
> "external" debug symbols like dwarf directories...

Yes, debug options are compiler dependent to balance between speed
optimization and ease of debugging. For instance, gcc recommends:

----https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
If you are not using some other optimization option, consider using -Og
(see Optimize Options) with -g. With no -O option at all, some compiler
passes that collect information useful for debugging do not run at all,
so that -Og may result in a better debugging experience.
----

I would expect alpha and possibly beta to use debug but RC or release
versions to optimize aggressively for speed. Debug builds may be
instrumented for bounds check, initialized alloc, leak checks, overflow
checks etc. These could slow down squeak vm.

Regards .. Subbu

 

That _really_ depends. And actually, why should writing debug info into the binary slow things down?
It at most increases the size of the binary. Optimization on GCC/clang is only handled via the -O?? flag.

In fact, on OSX a common pattern is (was?) to compile with debug symbols but not put them in the binary but a directory besides it.
That way you can distribute the Binary w/o the debug symbols but have them handy in case you need to debug the release binary on your end.

TL;DR: there is really no need to remove '-g' on gcc/clang, even in release builds.

Best regards
        -Tobias

 
On 06/04/20 11:42 AM, Tobias Pape wrote:
>  
>
>> On 06.04.2020, at 08:00, K K Subbu<[hidden email]>  wrote:
>>..I would expect alpha and possibly beta to use debug but RC or release versions to optimize aggressively for speed. Debug builds may be instrumented for bounds check, initialized alloc, leak checks, overflow checks etc. These could slow down squeak vm.
> That_really_  depends. And actually, why should writing debug info into the binary slow things down?
> It at most increases the size of the binary. Optimization on GCC/clang is only handled via the -O?? flag.

It is not just debug info. Read my reasons carefully - debug options may
insert code for bounds check, initialize malloc memory etc.

> TL;DR: there is really no need to remove '-g' on gcc/clang, even in release builds.

It would be easy to check if -g has an impact on performance. Just
generate a bintray build with just "-O3" and we can run a quick
benchmark to check if there is any significant impact on the
performance. This will give us hard data to make a decision. If there is
no impact, then your may revert to status quo.

Regards .. Subbu