On Fri, Jan 7, 2022 at 3:51 PM Ryan Kavanagh <[email protected]> wrote:
> Control: tags -1 + confirmed
> Control: retitle -1 mlton cannot rebuild itself on hppa or i386
>
> On Thu, Jan 06, 2022 at 07:55:00PM +0000, John David Anglin wrote:
> > It fails with a reproducible segmentation fault.
>
> I can reproduce this even with the latest upstream HEAD on the hppa
> porterbox, using
>
> make BOOTSTRAP_STYLE=3
>
> which makes it this far:
>
> -----8<---------
> make compiler SELF_COMPILE=true CHECK_FIXPOINT=true # tools2 + mlton2
> -> mlton3; mlton3 == mlton2
> [...]
> chmod -w front-end/mlb.grm.*
> sed \
> -e "s/MLTON_NAME/MLton/" \
> -e "s/MLTON_VERSION/????????/" \
> < control/version_sml.src \
> > control/version.sml
> (cat control/version_sml.src; echo 'MLton' '????????'; cat
> control/version.sml) | sha1sum | sed 's/.*\([a-z0-9]\{40\}\).*/\1/' >
> control/version_sml.chk
> Compiling mlton
> "/home/rak/mlton/build/bin/mlton" \
> @MLton ram-slop 0.7 gc-summary -- \
> -default-ann 'sequenceNonUnit warn' -default-ann 'warnUnused true'
> -verbose 2 \
> -target self -output mlton-compile \
> mlton.mlb
> MLton ???????? starting
> Compile SML starting
> frontend starting
> parseAndElaborate starting
> Segmentation fault
> make[2]: *** [Makefile:72: mlton-compile] Error 139
> make[2]: Leaving directory '/home/rak/mlton/mlton'
> make[1]: *** [Makefile:75: compiler] Error 2
> make[1]: Leaving directory '/home/rak/mlton'
> make: *** [Makefile:29: all] Error 2
> -----8<---------
>
This looks like the "old" MLton successfully compiled the "new" mlton
(mlton1), which then went on to successfully compile the tools (mllex,
mlyacc, ...) and a second round of self-compilation (mlton2), which itself
went on to successfully compile the tools, but failed when trying to
perform a third round of self-compile (mlton3). That's pretty surprising.
To get some debugging information, I would suggest compiling with
`MLTON_COMPILE_ARGS="-keep g -debug true"`. The "-keep g" instructs MLton
to keep the generated .c files and the "-debug true" instructs MLton to
compile the generated .c files with "-g" and to link to a version of the
runtime system itself compiled with "-g".
On HPPA, MLton doesn't have a native codegen, so the default is `-codegen
c`.
> On Thu, Jan 06, 2022 at 06:04:18PM -0600, Henry Cejtin wrote:
> > ssume that it isn't reproducible on AMD, right?
> > Or better, x86 (32 bit)?
>
> Not reproducible on amd64, but it is reproducible on i386, even with
> codegen c:
>
> make BOOTSTRAP_STYLE=3 MLTON_COMPILE_ARGS='-codegen c'
>
> segfaults at
>
> -----8<---------
> make compiler CHECK_FIXPOINT=false # tools0 + mlton0
> -> mlton1
> make[1]: Entering directory '/home/rak/i386/mlton-20210117+dfsg'
> make -C "/home/rak/i386/mlton-20210117+dfsg/mlton"
> make[2]: Entering directory '/home/rak/i386/mlton-20210117+dfsg/mlton'
> Compiling mlton
> "mlton" \
> @MLton ram-slop 0.7 gc-summary -- \
> -verbose 2 \
> -target self -output mlton-compile \
> mlton-stubs.mlb
> MLton 20210117+dfsg-3 starting
> Compile SML starting
> frontend starting
> parseAndElaborate starting
> Segmentation fault
> -----8<---------
>
This looks like the "old" MLton didn't get very far compiling the "new"
MLton. The `MLTON_COMPILE_ARGS="-codegen c"` doesn't have any effect,
because those are only used when the "new" MLton is performing a second or
third round of self-compiling. (You could use `OLD_MLTON_COMPILE_ARGS` to
influence the "old" MLton compiling the "new" MLton; this isn't even
getting to the point where the choice of codegen would have any effect.)
Of course, my understanding is that with Ryan's work, the "old" MLton isn't
even really that old --- it's just a binary package of the current sources,
considered "old" enough to be used as a prereq for building the sources.
Is there any chance that the issue is due to a (potential) mismatch
> between flags involving pic/pie we pass in via -cc-opt $(CFLAGS), and
> the default target-determined default? mlton has the flags -pi-style and
> -native-pic thanks to https://github.com/MLton/mlton/pull/365 that may
> need setting. (I haven't yet investigated this.) Debian used to carry a
> patch that forced PIC to fix a FTBFS on amd64, and I dropped it this
> most recent release because I thought it was no longer required (mlton
> built fine without it).
>
By default (i.e., without explicitly setting the `-pi-style` flag), MLton
should simply follow the behavior of the C compiler (and will not pass any
special flags to the C compiler). Typically, a mismatch involving pic/pie
manifests as a linking error, because one object file isn't using a symbol
in a way compatible with the defining object file.
