GitLab

David Eichmann pushed to branch wip/davide/ghc-internal-def at Glasgow Haskell Compiler / GHC

Commits:

d8dd0703

by Julian Ospald at 2025-11-21T14:06:02+08:00

Use libffi-clib

Previously, we would build libffi via hadrian
and bundle it manually with the GHC bindist.

This now moves all that logic out of hadrian
and allows us to have a clean Haskell package
to build and link against and ship it without
extra logic.

This patch still retains the ability to link
against a system libffi.

The main reason of bundling libffi was that on
some platforms (e.g. FreeBSD and Mac), system libffi
is not visible to the C toolchain by default,
so users would require settings in e.g. cabal
to be able to compile anything.

This adds the submodule libffi-clib to the repository.

8ba3e6ee

by Matthew Pickering at 2025-11-21T14:06:18+08:00

hadrian: Use a response file to invoke GHC for dep gathering.

In some cases we construct an argument list too long for GHC to
handle directly on windows. This happens when we generate
the dependency file because the command line will contain
references to a large number of .hs files.

To avoid this we now invoke GHC using a response file when
generating dependencies to sidestep length limitations.

Note that we only pass the actual file names in the dependency
file. Why? Because this side-steps #26560

c4c5cc8d

by Duncan Coutts at 2025-12-05T12:05:51+00:00

Make cmm 'import "package" name;' syntax use consistent label types

There is a little-used syntactic form in cmm imports:

import "package" foo;

Which means to import foo from the given package (unit id, specified as
a string). This syntax is somewhat reminiscent of GHC's package import
extension.

This syntax form is not used in the rts cmm code, nor any of the boot
libraries. It may not be used at all. Unclear.

Change the kind of CLabel this syntax generates to be consistent with
the others. The other cmm imports use ForeignLabel with
ForeignLabelInExternalPackage. For some reason this form was using
CmmLabel. Change that to also be ForeignLabel but with
ForeignLabelInPackage. This specifies a specific package, rather
than an unnamed external package.

089becd4

by Duncan Coutts at 2025-12-05T12:06:09+00:00

Change default cmm import statements to be internal

Previously a cmm statement like:

import foo;

meant to expect the symbol from a different shared library than the
current one.

Now it means to expect the symbol from the same shared library as the
current one. We'll add explicit syntax to indicate that it's a foreign
import. Most existing uses are in fact intenal (rts to rts), so few
imports will need to be annotated foreign. Examples would include cmm
code in libraries (other than the rts) that need to access RTS APIs.

In practice, this makes no difference whatsoever at the moment on any
platform other than windows (where building Haskell libs as shared libs
does not fully work yet), since the 'labelDynamic' treats all such
labels as foreign, irrespective of the foreign label source.

ebbfa6d3

by Duncan Coutts at 2025-12-05T12:06:16+00:00

Add cmm import syntax 'import DATA foo;' as better name for CLOSURE

The existing syntax is:

import CLOSURE foo;

The new syntax is

import DATA foo;

This means to interpret the symbol foo as refering to data (i.e. a
global constant or variable) rather than to code (a function). The
historical syntax for this uses CLOSURE, which is rather misleading.
Presumably this was done to avoid introducing new reserved words.

Be less squemish about new reserved words and add DATA and use that.
Keep the existing CLOSURE syntax as an alias for compatibility.

244b8b2b

by Duncan Coutts at 2025-12-05T12:10:27+00:00

Add cmm 'import extern name;' syntax

Since the default for cmm imports is now for symbols within the same
shared object, we need a way to indicate we want a symbol from an
external shared object:

import extern foo;      -- for a function
import extern DATA foo; -- for data

This adds a new reserved word 'extern'.

We don't expect to have to use this much. Most cmm imports are
intra-DSO.

This makes no difference currently on ELF and MachO platforms, but does
make a difference to the linking conventions on PE (Windows).

In future it's plausible we could take make distinctions on ELF or
MachO, so it's worth trying to get it right. Windows can be the guinea
pig.

06a95576

by Duncan Coutts at 2025-12-05T12:28:04+00:00

Add cmm syntax 'import "package" DATA foo;' for completeness

We already have:

import DATA foo;      -- for data imports
import "package" foo; -- for imports from a given unitid

There's no reason not to have both at once:

import "package" DATA foo;

So add that.

2e4c159b

by Duncan Coutts at 2025-12-05T12:28:04+00:00

Improve the commentary for the cmm import grammar.

AFAIK, this is the only place where GHC-style Cmm syntax is documented.

fd2954cd