[M3devel] CM3 status

[Tony Hosking]

I didn't OK dropping SPARC stack walking, just agreeing that we should move all platforms to gcc-supported stack walking.

On Dec 30, 2010, at 7:01 AM, Jay K wrote:

> Tony ok'ed this for Solaris/sparc32 a few months ago. I couldn't get it working with gcc 4.5, not even without optimization.
>   That was the last step in moving off of gcc 4.3 backend.

I wasn't real happy about dropping stack walking for Solaris.  It should not be difficult to retain.  I thought you were going to try to fix m3cg 4.5 to handle it.  My preference would be to retain the stack walking code on Solaris/SPARC (since it is so easy to do...) modulo making sure that m3cg 4.5 could cope with it.

> Alpha/OSF also doesn't work. I didn't look much into it, and I really don't think it matters.
>   It is an extremely little used platform. This year I saw it work on 4.0 and 5.1 but otherwise
>   it had been unused for several years I believe, and I don't see its use continuing much.

Last time I ran M3 on Alpha/OSF it did work.

> Upgrade of Solaris/sparc32 from gcc 4.3 to 4.5:
> 
> 2010-10-13 11:18  jkrell
> 
>   * m3-sys/cminstall/src/config-no-install/SPARC32_SOLARIS.common,
>     m3-sys/m3cc/gcc/gcc/m3cg/parse.c, m3-sys/m3cc/src/clean_marker.txt,
>     m3-sys/m3cc/src/m3makefile, m3-libs/m3core/src/runtime/m3makefile,
>     m3-sys/m3middle/src/Target.m3,
>     m3-libs/m3core/src/runtime/SOLgnu/m3makefile,
>     m3-libs/m3core/src/runtime/SOLgnu/m3makefile-old,
>     m3-libs/m3core/src/runtime/SOLsun/m3makefile,
>     m3-libs/m3core/src/runtime/SOLsun/m3makefile-old:
> 
>   disable Solaris/sparc32 stack walker
>   switch Solaris/sparc32 to gcc 4.5 backend
>   function.c: make failure to volatilize when setjmp/vfork present an error
>     instead of a warning
>   add missing volatilization
>   pin Solaris/sparc32 at -O1 in the config file as -O2/-O3 were
>     seen to hit internal compiler errors (assertion failures)
>   remove the "all volatile" paths from parse.c (since they
>     were only for Solaris/sparc32's stack walker)
> 
> 
> Tony ok'ing (in my interpretation) the abandonment of our stack walker:
> 
> https://mail.elegosoft.com/pipermail/m3devel/2010-October/008019.html
> 
> 
> At least that was my interpretation.
> Using gcc's exception handling support and *its* stack walker (libgcc/libunwind)
> should provide the better and more portable functionality on many platforms.
> I'm not certain what'd it look like on systems where gcc isn't the usual C compiler (e.g. Solaris)
> but it's bound to work well on Linux, NetBSD, FreeBSD, OpenBSD, and Solaris using gcc.
> "more portable" as in, across all architectures.
> 
> 
> Perhaps I should have stuck back with 4.3 until implementing this however.
> 
> 
> It is definitely a step backward to not have the stack walker on Solaris/sparc32,
> but that is the only platform in years that has had one, and it is not terrible
> to have every platform on gcc 4.5.2 and not sprinkling volatile around.
> There are some backward steps but definitely a lot forward.
>   I tried using 5.4.0 tonight and I didn't get far.
> 
> 
> > o possibly unsafe OS calls in new C code (this may be a wrong deduction
> > from my side)
> 
> 
> I don't know what this is referring to.
> The Enable/DisableScheduling? I all but undid that.
> It should be in a few functions, e.g. malloc/free/realloc/calloc/opendir/readdir/closedir/fopen/fclose.
> Some of those it already is in. With OpenBSD moving to pthreads it matters less.
> It only matters for user threads.
> 
> 
> > o GUI input not working for BadBricks and other games (only on Darwin?)
> 
> 
> Yes this is still a problem, and occurs in 5.8.6 release, on Darwin local X Server.
> Doesn't reproduce when remoted to Cygwin/X. Other X apps do work locally.
> Not understood.
> It'd be good to get confirmation if/when they ever worked.
> 
> 
> > o no clean way for exception handling with current gcc
> 
> 
> This is how things have *always* been, *except* on Alpha/OSF and Solaris/sparc32.
> Those two platforms have "regressed", but for Solaris/sparc32 it was discussed and
> Alpha/OSF I really don't think is important.
> 
> 
> Exception handling has always been very inefficient on all but approx. those two platforms.
> It has always been desirable to fix.
> 
> The inefficiency has a few parts. Mainly that "try" costs pthread_getspecific and setjmp.
> The inefficiency of the actual throw/catch is not as worrisome.
> 
> 
> > o still alignment issues
> 
> 
> Details?
> 
> 
> > I'm concerned that things get tried out, don't work properly for all
> > our target platforms, but are left then and not cleaned up and something
> > else gets tried. I'm not sure this is correct, it is just me feeling
> > unwell after reading all those mails.
> 
> 
> Not really.
> 
> 
> 
> > Hudson and Tinderbox status seem to be mostly OK though, but I haven't
> > checked in detail (FreeBSD failing was a disk failure on my system
> > recently). But the tests don't cover all the things we should check.
> 
> 
> Yep I try to remember to check Hudson fairly regularly.
> I never look at Tinderbox though.
> 
> 
> > I think it would be good to have an overview of the projects/work that
> > is in progress or pending and its status. For example, we've imported
> > a new gcc version, but that doesn't seem to work well on all targets,
> > or does it? If not, how are we going to address this? Use older versions
> > on some platforms? Can I read up on that somewhere?
> 
> All platforms (except NT386) use gcc 4.5.2 for the backend.
>  (I did the upgrade after the release was made but before it was announced;
>   they delay announcement while it propagates to mirrors.)
> 
> 
> Ok, also ARM_DARWIN hypothetically uses 4.2.
> Apple forks gcc fairly aggressively.
> Perhaps we should merge the two forks. Perhaps.
> ARM_DARWIN isn't really supported currently. Probably that should be worked on.
> It'd also be interesting to see what Apple did to 4.2 for ppc/x86...
> 
> 
> > I'd like to suggest to simply use our Trac WiKi to document the ongoing
> 
> 
> Agreed but I'm lazy.
> I just throw "bombs" around..
> 
> 
>  - Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20101231/b802bd41/attachment-0002.html>