<html><head><base href="x-msg://904/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">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="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div class="hmmessage" 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 type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div class="hmmessage" 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 type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div class="hmmessage" 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">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>