From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: Simon Wright <simon@pushface.org>
Newsgroups: comp.lang.ada
Subject: Re: Setting up a bare metal x86 toolchain
Date: Sun, 23 Jun 2019 10:08:32 +0100
Organization: A noiseless patient Spider
Message-ID: <ly1rzk8y9b.fsf@pushface.org>
References: <c21e34d6-19d6-4876-ad61-f0e20f504ded@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org;
 posting-host="dd181267ad915841fd2f0710e0c41c52";
	logging-data="10943"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX19xpUK24kdFBPtPNe2HDq+jKWfFeWgbSLU="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (darwin)
Cancel-Lock: sha1:PghLE+wfFt+EmnIfHFI2oJ0tpL8=
	sha1:+heYxiEbrhWqI9ZrfLlQAqCB1a4=
Xref: reader01.eternal-september.org comp.lang.ada:56721
Date: 2019-06-23T10:08:32+01:00
List-Id: <comp.lang.ada>

ajxscc@gmail.com writes:

> I've recently begun exploring bare-metal development in Ada, with some
> great successes targeting bare-metal ARM using AdaCore's GPL
> compiler. I have some minimal experience with bare-metal x86
> development, and would like to use Ada for this purpose. I was
> wondering what the best way to create an x86 bare-metal toolchain is.
>
> I've seen Lucretia's 'Ada Bare Bones' tutorial on osdev.org, which
> provides some useful information about building the runtime. This is
> quite straightforward, but I'm a little unsure about how to build the
> cross compiler for the task.
>
> Am I correct in my assumption that creating a 'freestanding' binary is
> done by compiling with the right kind of RTS? If I were to
> create/utilise a proper freestanding RTS, would it be suitable to use
> either the AdaCore or FSF GNAT targeting x86?

In broad terms, hmm, but I think you're maybe developing on macOS? If
so, there's a possible problem with getting the assembler (clang
--cc1as) to do the right thing, and a definite problem with ld.

If you're on Linux, things should be a lot simpler (but I haven't
tried).

The following are all macOS-specific-ish.

$ /opt/gnat-ce-2019/bin/gcc -march=help -c dl.c
cc1: error: bad value ('help') for '-march=' switch
cc1: note: valid arguments to '-march=' switch are: nocona core2 nehalem
corei7 westmere sandybridge corei7-avx ivybridge core-avx-i haswell
core-avx2 broadwell skylake skylake-avx512 cannonlake icelake-client
icelake-server bonnell atom silvermont slm knl knm x86-64 eden-x2 nano
nano-1000 nano-2000 nano-3000 nano-x2 eden-x4 nano-x4 k8 k8-sse3 opteron
opteron-sse3 athlon64 athlon64-sse3 athlon-fx amdfam10 barcelona bdver1
bdver2 bdver3 bdver4 znver1 btver1 btver2 native

$ clang dl.c -march=help
error: unknown target CPU 'help'
note: valid target CPU values are: nocona, core2, penryn, bonnell, atom,
      silvermont, slm, goldmont, goldmont-plus, tremont, nehalem, corei7,
      westmere, sandybridge, corei7-avx, ivybridge, core-avx-i, haswell,
      core-avx2, broadwell, skylake, skylake-avx512, skx, cannonlake,
      icelake-client, icelake-server, knl, knm, k8, athlon64, athlon-fx,
      opteron, k8-sse3, athlon64-sse3, opteron-sse3, amdfam10, barcelona,
      btver1, btver2, bdver1, bdver2, bdver3, bdver4, znver1, x86-64

but what I can't at once see how to do is to get gcc to pass the
arcitecture option on to the assembler.

And in any case the macOS ld won't generate the sort of binary you'll
need for the bare machine; you need GNU ld.

So I think you'll need to do a full cross-compiler build.

I wrote up doing this for ARM at [1], and the current build scripts I've
used for ARM/GCC 9.1.0 are at [2].

In binutils.sh, you'd need to find out a replacement for --target that
covers the cpus you're going to support, and you won't need
--enable-interwork.

In gcc*.sh, again --target; I'm not sure what the x86 equivalent of
$MULTILIB_LIST (--with-multilib-list=rmprofile) would be - this says
"all Cortex-M cpus", basically.

In newlib.sh and gdb.sh, again --target.

[1]
https://forward-in-code.blogspot.com/2015/05/building-gcc-510-for-arm-eabi.html
[2] https://github.com/simonjwright/building-arm-eabi