[M3devel] Stuck on adding new cm3 target (AMD64_DRAGONFLY)
Jay K
jay.krell at cornell.edu
Mon Jan 20 00:15:02 CET 2014
The only problem I remember is an alignment matter using msvcrt.dll on AMD64_NT.
I'll look into it, and the old emails.
I've used the C backend on many platforms now.
- Jay
----------------------------------------
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; adacore at marino.st
> Subject: Re: [M3devel] Stuck on adding new cm3 target (AMD64_DRAGONFLY)
> Date: Sun, 19 Jan 2014 12:13:08 -0800
> From: mika at async.caltech.edu
>
>
> There were some bugs we never got around to addressing with the C backend,
> weren't there? A crash that didn't happen with native backend.
>
> I've been using the "native" at more or less the head on very recent
> Debian and the Raspberry Pi for a while now with no problems to speak of.
> (As long as you only use user threads... but that's another story, I think.)
>
> Mika
>
> Jay K writes:
>>--_f56ed036-02b3-494e-bb04-f7c58d07fa28_
>>Content-Type: text/plain; charset="iso-8859-1"
>>Content-Transfer-Encoding: quoted-printable
>>
>>I understand your reluctance.
>>
>>
>>> Is the goal just to get FreeBSD to have a binary with the latest
>>> sources?
>>
>>
>>Yes=2C and to make sure the build process works for you.
>>
>>
>>> Shouldn't FreeBSD use the C backend too?
>>
>>
>>Every target should. I haven't convinced everyone yet.
>>There is less resistance for new targets=2C like AMD64_NT and ARM_LINUX=2C =
>>which are working=2C using the C backend.
>>There are downsides to the C backend:
>> - it is slower to compiler =20
>> - debugging is degraded on systems that have m3gdb =20
>> (debugging is much better on systems w/o m3gdb)=20
>>
>>
>>And there are advantages not yet implemented=2C in particular=2C efficient =
>>exception handling by generating C++.
>>
>>
>>>> gcc/amd64 works for the same
>>>> for Linux=2C FreeBSD=2C OpenBSD=2C NetBSD=2C and Dragonfly.
>>>=20
>>> I assume you mean after the system understands this target. There will
>>> be a lot of files with __FreeBSD__ that need to be changed to
>>> __FreeBSD__ || __DragonFly__ as well. In any case=2C I'll have to
>>> regenerate a bunch of patches from my current work.
>>
>>
>>Your patches should apply fairly cleanly to any new checkout.
>>I am willing to through them and apply them to CVS if you want -- depends o=
>>n if you are ok with my stealing your credit=2C vs. you want to commit them=
>> yourselves.
>>I already skimmed them and they all look easy.
>>DragonflyBSD is basically FreeBSD by another name.
>>Yes=2C a ton of work has been done on the kernel=2C file systems=2C maybe p=
>>orts.
>>But the ABI is almost the same -- heck=2C for the most part=2C Linux=3D=3DN=
>>etBSD=3D=3DFreeBSD=3D=3DOpenBSD.
>>Sure=2C they might be implemented differently=2C but they are highly source=
>> compatible and every highly object code compatible.
>>
>>
>>> I must be misunderstanding what you mean by "upgrade". It's the
>>> cross-compiler that's complaining=2C and it was built by the latest patch=
>>es.
>>
>>Agreed=2C we are both missing something simple.
>>Usually this is the error you get when you don't upgrade Target.i3/Target.m=
>>3.
>>If you want to press on with the current approach and ignore my advise=2C i=
>>t should be possible to step through all this.
>>To start=2C break on Target__Init and see if it returns true or false.
>>
>>
>>> statically while a bug in the cm3 sources caused those libraries to link
>>> dynamically (which is why release binaries don't run on current FreeBSD)
>>
>>
>>Ugh. I saw something about that in your diffs. Definitely we intend to link=
>> statically.
>>I actually went to the trouble of removing use of gmp/mpfr/mpc in current s=
>>ource.
>>They are used for actually very little and aren't worth it.
>>
>>
>> - Jay
>>
>>
>>> Date: Sun=2C 19 Jan 2014 13:38:32 +0100
>>> From: adacore at marino.st
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Stuck on adding new cm3 target (AMD64_DRAGONFLY)
>>>=20
>>> On 1/19/2014 13:17=2C Jay K wrote:
>>>> Hey..I like that that does capture some of My Way.=20
>>>> Here is my independent off the cuff write up though:
>>>> I know the ports system is nice.
>>>> I know we really need to be in it for many operating systems.
>>>> I suspect your problem is that you didn't "upgrade" to apply you
>>>> changes at the right time.
>>>=20
>>> I must be misunderstanding what you mean by "upgrade". It's the
>>> cross-compiler that's complaining=2C and it was built by the latest patch=
>>es.
>>>=20
>>>=20
>>>> Do any of these work for you:
>>>> https://modula3.elegosoft.com/cm3/snaps/snapshot-index.html
>>>=20
>>> I'm not clear to which set you are referring.
>>> There's no need for a binary set=2C modula3 now builds on FreeBSD 9 and
>>> FreeBSD 10 (http://www.freshports.org/lang/modula3)=2C which is also
>>> superior to the release binaries because they link gmp and mpfr
>>> statically while a bug in the cm3 sources caused those libraries to link
>>> dynamically (which is why release binaries don't run on current FreeBSD)
>>>=20
>>> Then there are the source distributions=2C but they are from 2012 so they
>>> aren't exactly fresh either.
>>>=20
>>>=20
>>>> Anyway=2C please try this:=20
>>>> Ignore DragonFly at first.=20
>>>> Go to a system with a working cm3. Such as FreeBSD. Linux. Almost
>>>> anything.=20
>>>> Such as from ports.=20
>>>> Make a backup=2C e.g. of /usr/local/cm3.=20
>>>> My instructions are unfortunately destructive of the existing install=
>>.=20
>>>> Checkout the full current CVS repository.=20
>>>> In that repository=2C run scripts/python/upgrade.py.=20
>>>> If that doesn't work=2C stop=2C and we'll help.=20
>>>=20
>>> Is the goal just to get FreeBSD to have a binary with the latest
>>> sources? If so=2C I'd just modify the port to do that now that we have
>>> working binary bootstraps. The main reason I'm reluctant is that it
>>> took over a week to make the cm3 port=2C I've never had so much difficult=
>>y
>>> before. (I've also spent another week on the DragonFly port). So I'm
>>> "resisting" because of how much work it already took. That's why I was
>>> trying to port DragonFly=2C THEN update to latest rather than update to
>>> latest and then port DragonFly. (in other words=2C going forward seems a
>>> short path than backtracking)
>>>=20
>>>=20
>>>=20
>>>> If that does work=2C apply your diffs. And upgrade.py again. You can =
>>say
>>>> "upgrade.py skipgcc" here.=20
>>>> Then boot1.py c amd64_dragonflybsd =20
>>>> Make sure you say "c" and the target "amd64_dragonflybsd"=2C anywhe=
>>re
>>>> on the command line.=20
>>>> Ok=2C "c" is actually up to you. Since nobody messes with ABI much=
>>=2C
>>>> gcc/amd64 works for the same
>>>> for Linux=2C FreeBSD=2C OpenBSD=2C NetBSD=2C and Dragonfly.
>>>=20
>>> I assume you mean after the system understands this target. There will
>>> be a lot of files with __FreeBSD__ that need to be changed to
>>> __FreeBSD__ || __DragonFly__ as well. In any case=2C I'll have to
>>> regenerate a bunch of patches from my current work.
>>>=20
>>>=20
>>>> If this works=2C it will give you=2C roughly amd64_dragonflybsd*.tar.=
>>gz=20
>>>> Copy that to your Dragonfly system=2C extract it=2C cd into it=2C mak=
>>e.=20
>>>> If that works=2C you have a native cm3.=20
>>>> Run it. It should say "can't find cm3.cfg". =20
>>>> Now on Dragonfly=2C mkdir -p /usr/local/cm3/bin=20
>>>> cp cm3 /usr/local/cm3/bin =20
>>>> export PATH=3D/usr/local/cm3/bin:$PATH
>>>> full CVS checkout =20
>>>> cd scripts/python =3B ./boot2.sh=20
>>>> =20
>>>> You will need to have made small changes to pylib.py for this to work=
>>.
>>>> (And your config file should say to use the C backend=2C like Darwin =
>>and
>>>> ARM_LINUX do.)
>>>=20
>>>=20
>>> Well=2C I'm thrilled if I don't have to patch gcc again=2C that takes a l=
>>ong
>>> time. Shouldn't FreeBSD use the C backend too?
>>>=20
>>> John
>> =
>>
>>--_f56ed036-02b3-494e-bb04-f7c58d07fa28_
>>Content-Type: text/html; charset="iso-8859-1"
>>Content-Transfer-Encoding: quoted-printable
>>
>><html>
>><head>
>><style></style></head>
>><body class=3D'hmmessage'><div dir=3D'ltr'>I understand your reluctance.<br=
>>><br><br>>=3B Is the goal just to get FreeBSD to have a binary with the l=
>>atest<br>>=3B sources?<br><br><br>Yes=2C and to make sure the build proce=
>>ss works for you.<br><br><br>>=3B Shouldn't FreeBSD use the C backend too=
>>?<br><br><br>Every target should. I haven't convinced everyone yet.<br>Ther=
>>e is less resistance for new targets=2C like AMD64_NT and ARM_LINUX=2C whic=
>>h are working=2C using the C backend.<br>There are downsides to the C backe=
>>nd:<br> =3B - it is slower to compiler =3B <br> =3B - debugging=
>> is degraded on systems that have m3gdb =3B <br> =3B(debugging is m=
>>uch better on systems w/o m3gdb) <br><br><br>And there are advantages not y=
>>et implemented=2C in particular=2C efficient exception handling by generati=
>>ng C++.<br><br><br>>=3B >=3B gcc/amd64 works for the same<br>>=3B >=
>>=3B for Linux=2C FreeBSD=2C OpenBSD=2C NetBSD=2C and Dragonfly.<br>>=
>>=3B <br>>=3B I assume you mean after the system understands this target. =
>> There will<br>>=3B be a lot of files with __FreeBSD__ that need to be ch=
>>anged to<br>>=3B __FreeBSD__ || __DragonFly__ as well. In any case=2C I'=
>>ll have to<br>>=3B regenerate a bunch of patches from my current work.<br=
>>><br><br>Your patches should apply fairly cleanly to any new checkout.<br>I=
>> am willing to through them and apply them to CVS if you want -- depends on=
>> if you are ok with my stealing your credit=2C vs. you want to commit them =
>>yourselves.<br>I already skimmed them and they all look easy.<br>DragonflyB=
>>SD is basically FreeBSD by another name.<br>Yes=2C a ton of work has been d=
>>one on the kernel=2C file systems=2C maybe ports.<br>But the ABI is almost =
>>the same -- heck=2C for the most part=2C Linux=3D=3DNetBSD=3D=3DFreeBSD=3D=
>>=3DOpenBSD.<br>Sure=2C they might be implemented differently=2C but they ar=
>>e highly source compatible and every highly object code compatible.<br><br>=
>><br>>=3B I must be misunderstanding what you mean by "upgrade". It's the=
>><br>>=3B cross-compiler that's complaining=2C and it was built by the lat=
>>est patches.<br><br>Agreed=2C we are both missing something simple.<br>Usua=
>>lly this is the error you get when you don't upgrade Target.i3/Target.m3.<b=
>>r>If you want to press on with the current approach and ignore my advise=2C=
>> it should be possible to step through all this.<br>To start=2C break on Ta=
>>rget__Init and see if it returns true or false.<br><br><br>>=3B staticall=
>>y while a bug in the cm3 sources caused those libraries to link<br>>=3B d=
>>ynamically (which is why release binaries don't run on current FreeBSD)<br>=
>><br><br>Ugh. I saw something about that in your diffs. Definitely we intend=
>> to link statically.<br>I actually went to the trouble of removing use of g=
>>mp/mpfr/mpc in current source.<br>They are used for actually very little an=
>>d aren't worth it.<br><br><br> =3B- Jay<br><br><br><div>>=3B Date: Su=
>>n=2C 19 Jan 2014 13:38:32 +0100<br>>=3B From: adacore at marino.st<br>>=3B=
>> To: jay.krell at cornell.edu<br>>=3B CC: m3devel at elegosoft.com<br>>=3B Su=
>>bject: Re: [M3devel] Stuck on adding new cm3 target (AMD64_DRAGONFLY)<br>&g=
>>t=3B <br>>=3B On 1/19/2014 13:17=2C Jay K wrote:<br>>=3B >=3B Hey..I =
>>like that that does capture some of My Way. <br>>=3B >=3B Here is my in=
>>dependent off the cuff write up though:<br>>=3B >=3B I know the ports =
>>system is nice.<br>>=3B >=3B I know we really need to be in it for man=
>>y operating systems.<br>>=3B >=3B I suspect your problem is that you d=
>>idn't "upgrade" to apply you<br>>=3B >=3B changes at the right time.<br=
>>>>=3B <br>>=3B I must be misunderstanding what you mean by "upgrade". =
>>It's the<br>>=3B cross-compiler that's complaining=2C and it was built by=
>> the latest patches.<br>>=3B <br>>=3B <br>>=3B >=3B Do any of thes=
>>e work for you:<br>>=3B >=3B https://modula3.elegosoft.com/cm3/snaps/s=
>>napshot-index.html<br>>=3B <br>>=3B I'm not clear to which set you are =
>>referring.<br>>=3B There's no need for a binary set=2C modula3 now builds=
>> on FreeBSD 9 and<br>>=3B FreeBSD 10 (http://www.freshports.org/lang/modu=
>>la3)=2C which is also<br>>=3B superior to the release binaries because th=
>>ey link gmp and mpfr<br>>=3B statically while a bug in the cm3 sources ca=
>>used those libraries to link<br>>=3B dynamically (which is why release bi=
>>naries don't run on current FreeBSD)<br>>=3B <br>>=3B Then there are th=
>>e source distributions=2C but they are from 2012 so they<br>>=3B aren't e=
>>xactly fresh either.<br>>=3B <br>>=3B <br>>=3B >=3B Anyway=2C plea=
>>se try this: <br>>=3B >=3B Ignore DragonFly at first. <br>>=3B >=
>>=3B Go to a system with a working cm3. Such as FreeBSD. Linux. Almost<br>=
>>>=3B >=3B anything. <br>>=3B >=3B Such as from ports. <br>>=3B =
>>>=3B Make a backup=2C e.g. of /usr/local/cm3. <br>>=3B >=3B My in=
>>structions are unfortunately destructive of the existing install. <br>>=
>>=3B >=3B Checkout the full current CVS repository. <br>>=3B >=3B =
>>In that repository=2C run scripts/python/upgrade.py. <br>>=3B >=3B If=
>> that doesn't work=2C stop=2C and we'll help. <br>>=3B <br>>=3B Is the =
>>goal just to get FreeBSD to have a binary with the latest<br>>=3B sources=
>>? If so=2C I'd just modify the port to do that now that we have<br>>=3B =
>>working binary bootstraps. The main reason I'm reluctant is that it<br>>=
>>=3B took over a week to make the cm3 port=2C I've never had so much difficu=
>>lty<br>>=3B before. (I've also spent another week on the DragonFly port)=
>>. So I'm<br>>=3B "resisting" because of how much work it already took. =
>>That's why I was<br>>=3B trying to port DragonFly=2C THEN update to lates=
>>t rather than update to<br>>=3B latest and then port DragonFly. (in othe=
>>r words=2C going forward seems a<br>>=3B short path than backtracking)<br=
>>>>=3B <br>>=3B <br>>=3B <br>>=3B >=3B If that does work=2C appl=
>>y your diffs. And upgrade.py again. You can say<br>>=3B >=3B "upgrade.p=
>>y skipgcc" here. <br>>=3B >=3B Then boot1.py c amd64_dragonflybsd <=
>>br>>=3B >=3B Make sure you say "c" and the target "amd64_dragonflyb=
>>sd"=2C anywhere<br>>=3B >=3B on the command line. <br>>=3B >=3B =
>> Ok=2C "c" is actually up to you. Since nobody messes with ABI much=2C<br>&=
>>gt=3B >=3B gcc/amd64 works for the same<br>>=3B >=3B for Linux=2C=
>> FreeBSD=2C OpenBSD=2C NetBSD=2C and Dragonfly.<br>>=3B <br>>=3B I assu=
>>me you mean after the system understands this target. There will<br>>=3B=
>> be a lot of files with __FreeBSD__ that need to be changed to<br>>=3B __=
>>FreeBSD__ || __DragonFly__ as well. In any case=2C I'll have to<br>>=3B =
>>regenerate a bunch of patches from my current work.<br>>=3B <br>>=3B <b=
>>r>>=3B >=3B If this works=2C it will give you=2C roughly amd64_dragon=
>>flybsd*.tar.gz <br>>=3B >=3B Copy that to your Dragonfly system=2C ex=
>>tract it=2C cd into it=2C make. <br>>=3B >=3B If that works=2C you ha=
>>ve a native cm3. <br>>=3B >=3B Run it. It should say "can't find cm3.=
>>cfg". <br>>=3B >=3B Now on Dragonfly=2C mkdir -p /usr/local/cm3/bin =
>><br>>=3B >=3B cp cm3 /usr/local/cm3/bin <br>>=3B >=3B export P=
>>ATH=3D/usr/local/cm3/bin:$PATH<br>>=3B >=3B full CVS checkout <br>&g=
>>t=3B >=3B cd scripts/python =3B ./boot2.sh <br>>=3B >=3B <br>>=
>>=3B >=3B You will need to have made small changes to pylib.py for this =
>>to work.<br>>=3B >=3B (And your config file should say to use the C b=
>>ackend=2C like Darwin and<br>>=3B >=3B ARM_LINUX do.)<br>>=3B <br>>=
>>=3B <br>>=3B Well=2C I'm thrilled if I don't have to patch gcc again=2C t=
>>hat takes a long<br>>=3B time. Shouldn't FreeBSD use the C backend too?<=
>>br>>=3B <br>>=3B John<br></div> </div></body>
>></html>=
>>
>>--_f56ed036-02b3-494e-bb04-f7c58d07fa28_--
More information about the M3devel
mailing list