<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
<font style="font-size: 10pt;" face="Tahoma" size="2"><span style="font-size: 10pt;"> > Alpha/OSF also doesn't work</span></font><br><br><br>Clarification -- the target works, but not its stack walker.<br>I moved it back to setjmp/longjmp a few months ago when an Alpha/OSF machine was<br>presented to me, when the stack walker didn't work on the first try.<br><br>This stuff is fairly difficult to debug, reading the Alpha or Sparc assembly<br>to find the mistakes in it, and the payoff is very small...<br><br> - Jay<br><br><hr id="stopSpelling">From: jay.krell@cornell.edu<br>To: wagner@elegosoft.com; m3devel@elegosoft.com<br>Date: Thu, 30 Dec 2010 12:01:39 +0000<br>Subject: Re: [M3devel] CM3 status<br><br>
<meta http-equiv="Content-Type" content="text/html; charset=unicode">
<meta name="Generator" content="Microsoft SafeHTML">
<style>
.ExternalClass .ecxhmmessage P
{padding:0px;}
.ExternalClass body.ecxhmmessage
{font-size:10pt;font-family:Tahoma;}
</style>
> o at least 2 different compiler/assembler problems on Darwin/Snow Leopard<br><br><br>Needs more investigation.<br>Occurs in code not in our tree, with optimization.<br> The error message fyi is one that people occasionally see with mainline gcc also, though<br> hopefully not in recent releases. Something about a shortage of registers.<br>A significant codebase, not easily built, no small reproduction case yet presented or in hand.<br>Some of the problems are in release 5.8.6 but fixed in head.<br>But not all understood.<br><br><br>I suggest the code be added to our CVS and be made buildable and regularly built there.<br><br><br>> o current gcc not working on Solaris (?!)<br><br><br>I don't know what this is referring to.<br>Do you mean 4.5 vs. 4.3?<br>Well, sort of but really. Keep reading.<br><br><br>> o stack walker code abandoned<br><br><br>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.<br> That was the last step in moving off of gcc 4.3 backend.<br>Alpha/OSF also doesn't work. I didn't look much into it, and I really don't think it matters.<br> It is an extremely little used platform. This year I saw it work on 4.0 and 5.1 but otherwise<br> it had been unused for several years I believe, and I don't see its use continuing much.<br><br><br>Upgrade of Solaris/sparc32 from gcc 4.3 to 4.5:<br><br><pre>2010-10-13 11:18 jkrell<br><br> * m3-sys/cminstall/src/config-no-install/SPARC32_SOLARIS.common,<br> m3-sys/m3cc/gcc/gcc/m3cg/parse.c, m3-sys/m3cc/src/clean_marker.txt,<br> m3-sys/m3cc/src/m3makefile, m3-libs/m3core/src/runtime/m3makefile,<br> m3-sys/m3middle/src/Target.m3,<br> m3-libs/m3core/src/runtime/SOLgnu/m3makefile,<br> m3-libs/m3core/src/runtime/SOLgnu/m3makefile-old,<br> m3-libs/m3core/src/runtime/SOLsun/m3makefile,<br> m3-libs/m3core/src/runtime/SOLsun/m3makefile-old:<br><br> disable Solaris/sparc32 stack walker<br> switch Solaris/sparc32 to gcc 4.5 backend<br> function.c: make failure to volatilize when setjmp/vfork present an error<br> instead of a warning<br> add missing volatilization<br> pin Solaris/sparc32 at -O1 in the config file as -O2/-O3 were<br> seen to hit internal compiler errors (assertion failures)<br> remove the "all volatile" paths from parse.c (since they<br> were only for Solaris/sparc32's stack walker)<br><br><br>Tony ok'ing (in my interpretation) the abandonment of our stack walker:<br><br>https://mail.elegosoft.com/pipermail/m3devel/2010-October/008019.html<br><br><br>At least that was my interpretation.<br>Using gcc's exception handling support and *its* stack walker (libgcc/libunwind)<br>should provide the better and more portable functionality on many platforms.<br>I'm not certain what'd it look like on systems where gcc isn't the usual C compiler (e.g. Solaris)<br>but it's bound to work well on Linux, NetBSD, FreeBSD, OpenBSD, and Solaris using gcc.<br>"more portable" as in, across all architectures.<br><br><br>Perhaps I should have stuck back with 4.3 until implementing this however.<br><br><br>It is definitely a step backward to not have the stack walker on Solaris/sparc32,<br>but that is the only platform in years that has had one, and it is not terrible<br>to have every platform on gcc 4.5.2 and not sprinkling volatile around.<br>There are some backward steps but definitely a lot forward.<br> I tried using 5.4.0 tonight and I didn't get far.<br></pre><br><br>> o possibly unsafe OS calls in new C code (this may be a wrong deduction<br>> from my side)<br><br><br>I don't know what this is referring to.<br>The Enable/DisableScheduling? I all but undid that.<br>It should be in a few functions, e.g. malloc/free/realloc/calloc/opendir/readdir/closedir/fopen/fclose.<br>Some of those it already is in. With OpenBSD moving to pthreads it matters less.<br>It only matters for user threads.<br><br><br>> o GUI input not working for BadBricks and other games (only on Darwin?)<br><br><br>Yes this is still a problem, and occurs in 5.8.6 release, on Darwin local X Server.<br>Doesn't reproduce when remoted to Cygwin/X. Other X apps do work locally.<br>Not understood.<br>It'd be good to get confirmation if/when they ever worked.<br><br><br>> o no clean way for exception handling with current gcc<br><br><br>This is how things have *always* been, *except* on Alpha/OSF and Solaris/sparc32.<br>Those two platforms have "regressed", but for Solaris/sparc32 it was discussed and<br>Alpha/OSF I really don't think is important.<br><br><br>Exception handling has always been very inefficient on all but approx. those two platforms.<br>It has always been desirable to fix.<br><br>The inefficiency has a few parts. Mainly that "try" costs pthread_getspecific and setjmp.<br>The inefficiency of the actual throw/catch is not as worrisome.<br><br><br>> o still alignment issues<br><br><br>Details?<br><br><br>> I'm concerned that things get tried out, don't work properly for all<br>> our target platforms, but are left then and not cleaned up and something<br>> else gets tried. I'm not sure this is correct, it is just me feeling<br>> unwell after reading all those mails.<br><br><br>Not really.<br><br><br><br>> Hudson and Tinderbox status seem to be mostly OK though, but I haven't<br>> checked in detail (FreeBSD failing was a disk failure on my system<br>> recently). But the tests don't cover all the things we should check.<br><br><br>Yep I try to remember to check Hudson fairly regularly.<br>I never look at Tinderbox though.<br><br><br>> I think it would be good to have an overview of the projects/work that<br>> is in progress or pending and its status. For example, we've imported<br>> a new gcc version, but that doesn't seem to work well on all targets,<br>> or does it? If not, how are we going to address this? Use older versions<br>> on some platforms? Can I read up on that somewhere?<br><br>All platforms (except NT386) use gcc 4.5.2 for the backend.<br> (I did the upgrade after the release was made but before it was announced;<br> they delay announcement while it propagates to mirrors.)<br><br><br>Ok, also ARM_DARWIN hypothetically uses 4.2.<br>Apple forks gcc fairly aggressively.<br>Perhaps we should merge the two forks. Perhaps.<br>ARM_DARWIN isn't really supported currently. Probably that should be worked on.<br>It'd also be interesting to see what Apple did to 4.2 for ppc/x86...<br><br><br>> I'd like to suggest to simply use our Trac WiKi to document the ongoing<br><br><br>Agreed but I'm lazy.<br>I just throw "bombs" around..<br><br><br> - Jay<br> </body>
</html>