<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
Oops, you can see the ambiguity?<br><br><br>So you'd rather leave Solaris/sparc32 back on gcc-4.3 for now, if the gcc-supported stack walking isn't imminent? <br> And possibly volatile on load/store a lot. (That was more out of laziness maybe, I remember if I tried removing it.)<br> I don't like that, but I can do it.<br> Or is it imminent, by someone other than me?<br><br><br>gcc-4.5 even without any optimizations and volatile everywhere didn't work with the Solaris/sparc32 stack walker.<br>I tried a fair amount to debug it but gave up at the time.<br><br><br>I continue to assume that Alpha/OSF is even much less interesting, given that it has extremely few users.<br> The code continues to sit unused in CVS, same as it mostly ever did.<br><br><br><div> > Last time I ran M3 on Alpha/OSF it did work.</div><br><br>I ran it in 2010 and it didn't work.<br>I don't remember though if that was with gcc 4.3 or 4.5.<br>I could try again with 4.3, but I don't know what the result would be -- we'd leave it back with 4.3 also?<br><br><br> > 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<br> > ...modulo making sure that m3cg 4.5 could cope with it.<br><br><br>This was looking to be difficult. Even volatile everywhere and no optimization didn't work.<br>I could give it another try perhaps. Or maybe someone else can?<br>Getting it to work without any optimization and volatile on every load/store should be useful and easy, but it wasn't proving even easy.<br><br><br>I figure moving to 4.5 has a fair amount of value, and optimizing one platform Solaris/sparc32 uniquely beyond all others, is less so.<br><br><br>Or maybe I should look again more closely at the gcc stuff. Maybe it could be done imminently..<br>That would nicely remove a lot of target-dependent-ness out of the front/middle end!.<br><br><br> - Jay<br><br><br><hr id="stopSpelling">From: hosking@cs.purdue.edu<br>Date: Fri, 31 Dec 2010 17:01:27 -0500<br>To: jay.krell@cornell.edu<br>CC: m3devel@elegosoft.com<br>Subject: Re: [M3devel] CM3 status<br><br>
<meta http-equiv="Content-Type" content="text/html; charset=unicode">
<meta name="Generator" content="Microsoft SafeHTML">I didn't OK dropping SPARC stack walking, just agreeing that we should move all platforms to gcc-supported stack walking.<br>
<br><div><div>On Dec 30, 2010, at 7:01 AM, Jay K wrote:</div><br class="ecxApple-interchange-newline"><blockquote><span class="ecxApple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; font-size: medium;"><div class="ecxhmmessage" style="font-size: 10pt; font-family: Tahoma;">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></div></span></blockquote><div><br></div><div>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.</div><br><blockquote><span class="ecxApple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; font-size: medium;"><div class="ecxhmmessage" style="font-size: 10pt; font-family: Tahoma;">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></div></span></blockquote><div><br></div><div>Last time I ran M3 on Alpha/OSF it did work.</div><br><blockquote><span class="ecxApple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; font-size: medium;"><div class="ecxhmmessage" style="font-size: 10pt; font-family: Tahoma;">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><a href="https://mail.elegosoft.com/pipermail/m3devel/2010-October/008019.html" target="_blank">https://mail.elegosoft.com/pipermail/m3devel/2010-October/008019.html</a><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></div></span></blockquote></div><br> </body>
</html>