Re: Keep MLton from being kicked out of Debian?

On Mon, Nov 07, 2016 at 08:05:21PM -0500, Matthew Fluet wrote:
> On Mon, Nov 7, 2016 at 4:55 PM, Christopher Cramer
> > Yeah, I did exactly that (and also had to stick it into bin/upgrade-basis).
> 
> Make sense.  I've killed bin/upgrade-basis in master, because it is a
> pain (and hasn't really done anything for quite some time).

Unfortunately Debian is still using an old version of MLton. Wesley is MIA
and nobody has tried to replace him. I should probably do it.

> MLton supports PIC, it just does not assume that Linux requires PIC.
> Debian might patch to force using PIC; should be as simple as adding a
> case to:
>   https://github.com/MLton/mlton/blob/master/mlton/main/main.fun#L920
> 
> Of course, if you make that patch, then MLton will always generate PIC.

That seems like the way to go. Only I think Debian is defaulting
to PIC only on some architectures. Maybe only on AMD64. I don't
think PIE makes much sense on 32-bit architectures, for instance.

> And, this is where I haven't figured out what Debian is trying to
> achieve.  Is the PIC/PIE default gcc just during package building (so
> that executables within .deb packages are PIE), or is it also the
> behavior of an installed Debian system, so that a normal user invoking
> gcc will get the PIC/PIE default?  If the behavior of an installed
> Debian system is not to have a PIC/PIE default gcc, then you will end
> up with the awkward situation where MLton will (unnecessarily)
> generate PIC code, although I don't think it a problem if PIC object
> is linked with non-PIC objects into a non-PIE executable.

It's the default whether you're building a package or not. So right now
in unstable, the gcc default has already changed, and MLton on Debian
(whether you are using the Debian package or not; personally I am using
a customized package) is already broken unless you add those flags to
disable PIE. I hadn't noticed because, sadly, nobody is paying me to
use SML anymore...

So basically we need two patches:

1) one patch to add the flags to gcc to build MLton (using old MLton
binary already in Debian) without PIE, despite the new gcc default

2) another patch to set MLton to PIC code generation, when that is
the gcc default

Patch 1 can be thrown away after we build a new binary package.
Patch 2 goes in permanently.

> MLton should really support some kind of "-pie {false|true}" flag,
> whose default depends on the target platform.  But, by "target
> platform", we need something more specific than our past arch/os pair
> --- because amd64-linux Debian sid wants the default to be true, but
> amd64-linux Debian jessie wants (or at least allows) the default to be
> false, and other linux distros also allow the default to be false.
> Ideally, we would generate PIC/non-PIC assembly depending on the
> default behavior of the C compiler on the target and similarly link
> PIE/non-PIE depending on the default behavior, with options to
> override the default (passing the appropriate flags to the C
> compiler).

Yes. We could detect whether the gcc default is PIE or not during
build. For Linux, this will be distribution-dependent, and can evidently
change over time. When it changes, just rebuild MLton.

For now... I think the only native codegens are x86 and AMD64, right? So only
one case needs to change? Does PIC matter for the C codegen, or for the
LLVM codegen?

-- 
You received this message because you are subscribed to the Google Groups "MLton-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi