#4163: Make cross-compilation work
---------------------------------+------------------------------------------
Reporter: simonmar | Owner:
Type: task | Status: new
Priority: high | Milestone: 7.2.1
Component: Build System | Version: 6.12.3
Keywords: | Testcase:
Blockedby: | Difficulty: Difficult (2-5 days)
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
---------------------------------+------------------------------------------
Comment(by dankna):
Okay - I am about to attach a patch. I'd like this patch merged as soon
as possible, even though it only solves part of the problem, because of
its large size (wc says the diff is 6700 lines, so I assume it touches
about half that many). I'm terrified to death of having to redo the work
because of conflicts! :)
This patch does several things towards my first goal of removing all
preprocessor use from the compiler/ subtree.
First, it adds a new file basicTypes/Architecture.hs which contains a
taxonomy of platforms we support. This is distinct from the old
nativeGen/Platforms.hs (which this patch removes, changing all uses of it
to support the new system) in that it includes second- and even third-tier
platforms, not just those for which we have native generators available.
Currently there are three fields to it - Processor, Vendor, and Kernel.
Eventually there will be an additional field ABI (application binary
interface), holding all the information that's currently determined by GNU
autoconf, so that it's available at runtime. There is a new field
targetArchitecture :: Architecture in the dynamic flags, currently
initialized by the preprocessor; this should be easy to change to
initializing from the command-line when we get that far.
Second, it threads parameters of this Architecture type everywhere they're
needed. This mostly means to the preprocessor, or to functions which call
the preprocessor - which means practically everything, unfortunately.
Where it made sense to add it to a monad instead of making it an explicit
parameter, I did that, but it very seldom did. I did talk to dcoutts
about possible other strategies, and he agreed that this one made sense
(the channel logs of #ghc should have our full discussion, probably
sometime last week); there are several motivating forces, but most
notably, I can't make the type of Instruction determine how things are
pretty-printed, because some architectures share Instruction types but not
pretty-printing styles. I should note here that the pretty-printer is
used to interface with external tools, such as gcc and llvm, and is thus a
"mission-critical" component, not merely for debugging use!
Third, it takes out quite a lot of Outputable instances, replacing them
with functions in the style pprThing :: Architecture -> SDoc. Also
there's a couple in the style pprList :: (a -> SDoc) -> [a] -> SDoc. The
instances are no longer viable because the preprocessor had been used to
select which instance to use, and we need to make that determination at
runtime to support multiple targets from a single binary of ghc.
Generally the "damage" this caused was fairly limited, but a single
Outputable instance, that on CLabel, by its removal forced Architecture to
be threaded in both llvmGen/ and codeGen/ - I verified very carefully that
this was a genuine portability issue and not something I could stub around
by forking the implementation or something. The issue was that underscore
prefixing and other name-mangling had been controlled by the preprocessor,
and again, now we need to make the decision at runtime. The good news is
that I completed that part of the work!
Third, it reconciles and takes out some old notions that were grasping for
the same thing as the Architecture taxonomy but in less complete ways.
Specifically, this is done for nativeGen/Platform.hs (as noted above), and
for the elf_OBJ_FORMAT macro. I would like to note by way of bragging
that having threaded the Architecture made it very easy to take out the
elf_OBJ_FORMAT macro.
Fourth, it includes Igloo's patch above, and resolves conflicts that had
arisen in it. The full import of this patch is not clear to me, but
mostly it seems to be changing things to use *_TARGET_ARCH instead of
*_HOST_ARCH. To this extent, it may be irrelevant, since the ultimate
goal is to remove these altogether - and I believe that that's no more
than another two weeks of work away, at the worst, and probably less.
Future work will take out the IF_ARCH_* macros and the *_TARGET_ARCH
macros. I had originally planned to submit this for merging once that was
complete, but the patch in its current form does pass validate for me, or,
at least, causes no "unexpected failures" that I wasn't getting from HEAD
without my patch. But given the multi-architecture nature of this patch,
people should check that on other platforms as well!
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4163#comment:16>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
