[M3devel] Ubuntu problems

[Tony Hosking]

On Dec 16, 2007, at 1:56 AM, Mika Nystrom wrote:

>
> All right, thanks for your suggestions.  I seem to have made a
> working compiler.  Even mentor works on this Ubuntu 2.6.20.
>
> My main observation is that M3/Linux is crying out for a new bootstrap
> compiler binary.  Neither the one from Tony's site nor the 5.4.0
> cm3 is actually able to compile the CVS head.  The problems come
> from Long.m3 (instance of GenWord.mg) and Int64.i3.  I was able to
> work around these issues by putting in some garbage in these files
> and bootstrapping twice---the second time with the proper code in
> Long.m3 and Int64.i3.  It's not that the bootstrapping compiler  
> doesn't
> know about long (at least one of them does), it just crashes.  But
> no harm done, it all seems to work after fiddling with it.

I need to update my ftp site with a version of the Linux bootstrap  
compiler that will work for the LONGINT support.

> Another issue---and I feel stupid for asking, it seems so basic---is
> that Linux is really stingy with static archives (.a files), and
> my cm3.cfg was asking for -lXaw, which didn't work, even though
> there was a libXaw.so.6 present.  I changed the cfg to link explicitly
> with /usr/lib/libXaw.so.6, but that can't be the right way to do it??
> Oh the 5.4.0 cm3.cfg also wraps the "utimes" call.  I took this out,
> as no one was supplying wrap_utimes.  I take it this is safe... (a
> GC-related modification?)

You are working off of a very old cm3.cfg -- try the one from my ftp  
site.

>
>      Mika
>
> Mika Nystrom writes:
>> Sorry, I have now read the mailing list archives a bit better.
>>
>> I am going to try bootstrapping the latest CVS with Tony's cm3  
>> binary,
>> to use pthreads...
>>
>>   Mika
>>
>>
>> Mika Nystrom writes:
>>> Hello Modula-3 people,
>>>
>>> I am trying to build things with CM3 on a relatively recent Ubuntu
>>> system (don't ask me why...) and I am running into a segfault that
>>> I haven't seen mentioned before.  I have a feeling it has something
>>> to do with stack formats, but I'm not sure what to do next.
>>>
>>> I downloaded the cm3-5.4.0 binaries and started with that.  The
>>> compiler in the binary distribution runs, but it appears to produce
>>> garbage.  I first tried bootstrapping but it crashes the moment it
>>> tries to execute something it has compiled itself.  So then I tried
>>> hello, world, with the same results...
>>>
>>> Here's the system identification:
>>>
>>> mika at edwards:~/test/src$ uname -a
>>> Linux edwards 2.6.20-16-386 #2 Sun Sep 23 19:47:10 UTC 2007 i686  
>>> GNU/Linux
>>>
>>> I made a "hello, world" program as follows:
>>>
>>> MODULE Main;
>>> IMPORT IO;
>>>
>>> BEGIN IO.Put("Hello, world!\n") END Main.
>>>
>>> Compiled with cm3 directly from the distributed cm3-5.4.0 for
>>> LINUXLIBC6 and I get a crash in CsetjmpASM.s (as far as I can tell).
>>> The last unclobbered stack I seem to be able to get in m3gdb is
>>> this:
>>>
>>> Breakpoint 5, 0xb75e5fb4 in _setjmp () at ../src/C/LINUXLIBC6/ 
>>> CsetjmpASM.s:31
>>> 31      in ../src/C/LINUXLIBC6/CsetjmpASM.s
>>> (m3gdb) where
>>> #0  0xb75e5fb4 in _setjmp () at ../src/C/LINUXLIBC6/CsetjmpASM.s:31
>>> #1  0xb75dbd51 in RTThread__Transfer (from=0xbfe28530,  
>>> to=0xbfe28530) at ../s
>> r
>>> c/runtime/LINUXLIBC6/RTThreadC.c:14
>>> #2  0xb75dbaed in FlushStackCache () at RTThread.m3:65
>>> #3  0xb75e27c9 in DetermineContext (oldSP=Invalid C/C++ type code  
>>> 35 in symbo
>> l
>>> table.
>>> ) at ThreadPosix.m3:1101
>>> #4  0xb75e270d in InitTopContext (c=Invalid C/C++ type code 30 in  
>>> symbol tabl
>> e
>>> .
>>> ) at ThreadPosix.m3:1076
>>> #5  0xb75e4325 in Init () at ThreadPosix.m3:1498
>>> #6  0xb75c9592 in InitRuntime (p_argc=Invalid C/C++ type code 39  
>>> in symbol ta
>> b
>>> le.
>>> ) at RTLinker.m3:59
>>> #7  0x08048861 in main (argc=1, argv=0xbfe28824, envp=0xbfe2882c)  
>>> at _m3main.
>> m
>>> c:3
>>> (m3gdb) cont
>>> Continuing.
>>>
>>> Program received signal SIGSEGV, Segmentation fault.
>>> 0xa8dbaede in ?? ()
>>>
>>> s.sp was lately 16_b75af6b9, if that means anything at all.
>>>
>>> Oh yes, one more thing: setting LD_POINTER_GUARD to 0 before running
>>> the program has no effect on the crash.
>>>
>>> Any suggestions for how one might make progress on this?
>>>
>>>     Mika