[M3devel] CM3 status

[Jay K]

>   o at least 2 different compiler/assembler problems on Darwin/Snow Leopard


Needs more investigation.
Occurs in code not in our tree, with optimization.
  The error message fyi is one that people occasionally see with mainline gcc also, though
  hopefully not in recent releases. Something about a shortage of registers.
A significant codebase, not easily built, no small reproduction case yet presented or in hand.
Some of the problems are in release 5.8.6 but fixed in head.
But not all understood.


I suggest the code be added to our CVS and be made buildable and regularly built there.


>   o current gcc not working on Solaris (?!)


I don't know what this is referring to.
Do you mean 4.5 vs. 4.3?
Well, sort of but really. Keep reading.


>   o stack walker code abandoned


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.
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.


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/20101230/bb61199f/attachment-0002.html>