<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>Darn, there might still be problems -- i.e. running stubgen.<div>Though again, the C backend works to build the entire system.</div><div>And I think self-built gcc 5.2.0 helped.</div><div>I'd rather not depend on that though.</div><div><br></div><div>I'm increasingly leary of the weak linkages among compiler/assembler/linker.</div><div><br></div><div>Interesting note, if you try to build stock gcc 4.7.4 on 10.10.4 it crashes pretty early.</div><div><br></div><div>I'll keep poking around but it could be a while.</div><div>Anyone else running 10.10?</div><div><br></div><div>cm3cg is noticeably faster to run than the C backend, even on new machine.</div><div>Darn, I was hoping modern hardware would make it look better. :(</div><div><br></div><div> - Jay<br><br><br><div><hr id="stopSpelling">From: jay.krell@cornell.edu<br>To: m3devel@elegosoft.com<br>Date: Tue, 11 Aug 2015 10:47:57 +0000<br>Subject: Re: [M3devel] Mac 10.10?<br><br>
<style><!--
.ExternalClass .ecxhmmessage P {
padding:0px;
}
.ExternalClass body.ecxhmmessage {
font-size:12pt;
font-family:Calibri;
}
--></style>
<div dir="ltr"><div>I figured out a big problem in 10.10.4 using the gcc backend.</div><div>Probably the only problem.</div><div><br></div><div><br></div><div> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67183 </div><div> https://llvm.org/bugs/show_bug.cgi?id=24428 </div><div><br></div><div><br></div><div>I had previously hacked cm3cg to always be 10.4-compatible.</div><div>I don't like the tools to probe their host and tailor their</div><div>output to it, lest the output or the tools meant to be copied</div><div>to an older/newer host.</div><div><br></div><div><br></div><div>The bug is demonstrated clearly in my bug reports.</div><div><br></div><div><br></div><div>The bug is this:</div><div> 32bit </div><div> + 10.4 compatible </div><div> + gcc backend </div><div> + clang assembler </div><div><br></div><div> </div><div> gcc/cm3cg output "stubs' and "non-lazy pointers" in any order.</div><div> clang outputs them all stubs first, then non-lazy pointers.</div><div> When the order isn't like clang, the LLVM assembler doesn't match</div><div> up the refs and defs correctly, leading to function calls resolving</div><div> to somewhat arbitrary other functions.</div><div> </div><div><br></div><div> It is "like" a compiler bug, you get incorrect code, but it is an assembler bug.</div><div><br></div><div> </div><div> There are three classes of fix.</div><div> But nothing perfect/easy.</div><div> </div><div> </div><div> 1) Run the same assembler as gcc.</div><div> On my system this is "as" in path.</div><div> But I don't know if this is guaranteed to work.</div><div> I currently use gcc -x assembler as the assembler.</div><div> </div><div> </div><div> 2) Drop 10.4 support -- don't output the stubs.</div><div> </div><div> </div><div> 3) Change cm3cg to output all stubs before all non-lazy pointers.</div><div> I'd have to see if that is easy or wait for the gcc developers to offer a patch.</div><div> </div><div> </div><div> 4) Drop 32bit. :) 64bit never has stubs.</div><div> </div><div> </div><div> If gcc output object files directly, like most other compilers do, that'd fix it.</div><div> The C backend has no problem.</div><div> </div><div> </div><div> - Jay</div><br><br><div><hr id="ecxstopSpelling">From: jay.krell@cornell.edu<br>To: m3devel@elegosoft.com<br>Subject: RE: Mac 10.10?<br>Date: Sun, 9 Aug 2015 03:01:30 +0000<br><br>
<style><!--
.ExternalClass .ecxhmmessage P {
padding:0px;
}
.ExternalClass body.ecxhmmessage {
font-size:12pt;
font-family:Calibri;
}
--></style>
<div dir="ltr">And now 10.10 works.<div>I think what changed is switching to a self-built gcc 5.2.0 from the builtin "gcc" which is actually clang/llvm (frontend and backend). I'll have to try again with the builtin. Strange.<div><br></div><div><br></div><div>It was failing with the 4.7 gcc backend. i.e. with very little C.</div><div>And I believe it had failed with C backend (prior to the Builder.m3 problems).</div><div><br></div><div>I switched to the C backend for better debugging and it went away. I had somewhat accidentally also changed C compilers -- oops, too much change. Anyway, after I rebuild the entire system instead of just the compiler, I'll go back and try some more combinations and debug.. one has to learn a new debugger on this system too -- lldb replaces m3gdb, and the Xcode gui debugger was briefly working quite nicely but stopped working. :(</div><div><br></div><div><div>Is anyone else using 10.10 with the "builtin" gcc/clang?</div><div>Or maybe clang toolset on another platform?</div><div><br></div><div>Later,</div><div><span style="font-size:12pt;"> - Jay</span></div><div><br><br><div><hr id="ecxstopSpelling">From: jay.krell@cornell.edu<br>To: m3commit@elegosoft.com; m3devel@elegosoft.com<br>Subject: alloca(jmpbuf_size) is in<br>Date: Sun, 9 Aug 2015 01:31:14 +0000<br><br>
<style><!--
.ExternalClass .ecxhmmessage P {
padding:0px;
}
.ExternalClass body.ecxhmmessage {
font-size:12pt;
font-family:Calibri;
}
--></style>
<div dir="ltr">I've seen it work now on AMD64_LINUX, SPARC32_SOLARIS, and I386_DARWIN 10.5.8.<div>I think MacOSX 10.10.4 has something else wrong with it that'll take a while to figure out.</div><div><br></div><div><br></div><div>So I commited it again.</div><div><br></div><div><br></div><div>PLEASE NOTE that the upgrade procedure is tricky like with cm3cg, but the </div><div>results of getting it wrong are worse than the recent round of cm3cg changes.</div><div>You will get runtime crashes.</div><div><br></div><div><br></div><div><br></div><div>upgrade.py and upgrade-full.sh and likely upgrade.sh all do the right thing, same as always.</div><div><br></div><div><br></div><div>Not only is cm3 closely tied with cm3cg, but it also closely tied with m3core.</div><div>The compiler and runtime collaborate on producing and consuming certain data structures,</div><div>and these data structures have changed now.</div><div><br></div><div><br></div><div><br></div><div>At least it should be more debuggable now with the C backend -- so I can see local variables for example.</div><div>Fixing cm3cg to work with plain -g would be good.</div><div><br></div><div><br></div><div>Is anyone else running 10.10?</div><div><br></div><div><br></div><div>Thanks,</div><div> - Jay<br><br><br><div><hr id="ecxstopSpelling">From: jay.krell@cornell.edu<br>To: m3commit@elegosoft.com<br>Date: Sat, 8 Aug 2015 18:59:55 +0000<br>Subject: Re: [M3commit] [modula3/cm3] 57ad34: Revert "allocate jmpbufs with alloca(external vari...<br><br>
<style><!--
.ExternalClass .ecxhmmessage P {
padding:0px;
}
.ExternalClass body.ecxhmmessage {
font-size:12pt;
font-family:Calibri;
}
--></style>
<div dir="ltr">I believe this is working ok on MacOS X 10.5.8 with cm3cg and C backend.<div>However things do not work on 10.10.4. I'm guessing for another unknown</div><div>reason but I want <span style="font-size:12pt;">to debug that separately for now.</span></div><div><br></div><div>If anyone else can give the previous a try on their configuration, that'd be appreciated.</div><div>(In github app, you can revert my revert. I haven't found how to do w/ git command line).</div><div><br></div><div>Thank you.</div><div><br></div><div>Specifically on 10.0.4 I get:</div><div><br></div><div><div>* thread #1: tid = 0x3a9861, 0x002b7360 cm3`RTAllocator__GetTracedObj + 36, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x24)</div><div> frame #0: 0x002b7360 cm3`RTAllocator__GetTracedObj + 36</div><div> * frame #1: 0x002b6e90 cm3`RTHooks__AllocateTracedObj + 17</div><div> frame #2: 0x00281272 cm3`TextUtils_M3 + 49</div><div> frame #3: 0x002c705c cm3`RTLinker__RunMainBody + 763</div><div> frame #4: 0x002c6f2d cm3`RTLinker__RunMainBody + 460</div><div> frame #5: 0x002c6f2d cm3`RTLinker__RunMainBody + 460</div><div> frame #6: 0x002c6f2d cm3`RTLinker__RunMainBody + 460</div><div> frame #7: 0x002c6f2d cm3`RTLinker__RunMainBody + 460</div><div> frame #8: 0x002c6f2d cm3`RTLinker__RunMainBody + 460</div><div> frame #9: 0x002c6f2d cm3`RTLinker__RunMainBody + 460</div><div> frame #10: 0x002c6f2d cm3`RTLinker__RunMainBody + 460</div><div> frame #11: 0x002c6f2d cm3`RTLinker__RunMainBody + 460</div><div> frame #12: 0x002c6f2d cm3`RTLinker__RunMainBody + 460</div><div> frame #13: 0x002c6f2d cm3`RTLinker__RunMainBody + 460</div><div> frame #14: 0x002c6f2d cm3`RTLinker__RunMainBody + 460</div><div> frame #15: 0x002c6f2d cm3`RTLinker__RunMainBody + 460</div><div> frame #16: 0x002c64e8 cm3`RTLinker__AddUnitI + 287</div><div> frame #17: 0x002c6563 cm3`RTLinker__AddUnit + 116</div><div> frame #18: 0x00002341 cm3`main(argc=1, argv=0xbffffca8, envp=0xbffffcb0) + 97 at _m3main.c:22</div><div> frame #19: 0x9518e6d9 libdyld.dylib`start + 1</div></div><div><br></div><div><br></div><div> - Jay</div><div><br><br><div>Date: Sat, 8 Aug 2015 11:49:10 -0700<br>From: jay.krell@cornell.edu<br>To: m3commit@elegosoft.com<br>Subject: [M3commit] [modula3/cm3] 57ad34: Revert "allocate jmpbufs with alloca(external vari...<br><br><pre> Branch: refs/heads/master<br> Home: <a href="https://github.com/modula3/cm3" target="_blank">https://github.com/modula3/cm3</a><br> Commit: 57ad34f5034d5000bd5d63fb384851921bc782a1<br> <a href="https://github.com/modula3/cm3/commit/57ad34f5034d5000bd5d63fb384851921bc782a1" target="_blank">https://github.com/modula3/cm3/commit/57ad34f5034d5000bd5d63fb384851921bc782a1</a><br> Author: jaykrell <jay.krell@cornell.edu><br> Date: 2015-08-08 (Sat, 08 Aug 2015)<br> <br> Changed paths:<br> M m3-libs/m3core/src/runtime/ex_frame/RTExFrame.m3<br> M m3-sys/m3back/src/M3C.m3<br> M m3-sys/m3cc/gcc/gcc/m3cg/parse.c<br> R m3-sys/m3front/src/misc/Jmpbufs.i3<br> R m3-sys/m3front/src/misc/Jmpbufs.m3<br> M m3-sys/m3front/src/misc/M3.i3<br> M m3-sys/m3front/src/misc/Marker.i3<br> M m3-sys/m3front/src/misc/Marker.m3<br> M m3-sys/m3front/src/misc/m3makefile<br> M m3-sys/m3front/src/stmts/TryFinStmt.m3<br> M m3-sys/m3front/src/stmts/TryStmt.m3<br> M m3-sys/m3front/src/values/Module.i3<br> M m3-sys/m3front/src/values/Module.m3<br> M m3-sys/m3front/src/values/Procedure.m3<br> M m3-sys/m3middle/src/M3RT.m3<br> M m3-sys/m3middle/src/Target.i3<br> M m3-sys/m3middle/src/Target.m3<br> <br> Log Message:<br> -----------<br> Revert "allocate jmpbufs with alloca(external variable initialized in C)"<br> <br>This reverts commit 44fbd1608a73affa0625a9df4bff1c7248cc6f3c.<br> <br> <br></pre><br>_______________________________________________
M3commit mailing list
M3commit@elegosoft.com
https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3commit</div></div> </div>
<br>_______________________________________________
M3commit mailing list
M3commit@elegosoft.com
https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3commit</div></div> </div></div></div></div></div> </div></div> </div>
<br>_______________________________________________
M3devel mailing list
M3devel@elegosoft.com
https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel</div></div> </div></body>
</html>