Porting to a new target

I am not certain if this question is better suited for cfe-dev or cfe-users, so I am starting here.

I am looking at using Clang to compile to a target that currently has no support. Actual target isn’t important, so much as that it isn’t currently supported and I am trying to learn the process of retargeting from the ground up.

Obviously, a big step (first?) step is writing a backend for the new target. After that it is necessary to get the C and C++ runtimes working. After that it shouldn’t be too hard to get the C and C++ standard libraries working.

What pieces are needed for the who processes? My guess would be the following:

  1. Compiler (Clang and LLVM)
  2. C++ library (libc++)
  3. C library (PDCLib?)
  4. ABI (libc++abi)

Am I missing anything? Are the C and C++ runtimes part of the ABI or are they a different piece? Also, what C library would people recommend using?

I am not certain if this question is better suited for cfe-dev or cfe-users, so
I am starting here.

cfe-dev is good for this kind of frontend-ey thing.
llvmdev is good for "I'm having X problem writing my backend".

I am looking at using Clang to compile to a target that currently has no
support. Actual target isn't important, so much as that it isn't currently
supported and I am trying to learn the process of retargeting from the ground up.

Obviously, a big step (first?) step is writing a backend for the new target.
After that it is necessary to get the C and C++ runtimes working. After that it
shouldn't be too hard to get the C and C++ standard libraries working.

What pieces are needed for the who processes? My guess would be the following:

0. QEMU or some other emulator
   Not an absolute must, but super useful if you don't real hardware yet, or your hardware doesn't have good debug support.

1. Compiler (Clang and LLVM)

1.25 Linker
   You could port ld, or lld.
1.5. Compiler runtimes (libgcc or compiler_rt).
   For compiler_rt, you can probably skip the sanitizers in your first stab at it. Save them for after you've got the regular bits working.
1.75 Debugger
   Not an absolute must, but suuuuper useful.
   Could port gdb, or lldb.

2. C++ library (libc++)

Or libstdc++

3. C library (PDCLib?)
4. ABI (libc++abi)

Or libcxxrt, or libsupc++.
5. Unwinder (sort of part of libc++abi, or libgcc_s)

Order-wise, I'd do: 0, (1, 1.25, and 1.5), then 1.75, then 3, the (4, and 5), and finally 2.

Am I missing anything? Are the C and C++ runtimes part of the ABI or are they a
different piece? Also, what C library would people recommend using?

There's good support for glibc.

Newlib is another choice, but support for it isn't all in trunk yet (I have some out-of-tree patches for this that I'm slowly upstreaming (mostly libc++)).

Cheers,

Jon

0. QEMU or some other emulator

  Not an absolute must, but super useful if you don't real hardware yet,
or your hardware doesn't have good debug support.

1. Compiler (Clang and LLVM)

1.25 Linker
  You could port ld, or lld.
1.5. Compiler runtimes (libgcc or compiler_rt).
  For compiler_rt, you can probably skip the sanitizers in your first stab
at it. Save them for after you've got the regular bits working.
1.75 Debugger
  Not an absolute must, but suuuuper useful.
  Could port gdb, or lldb.

2. C++ library (libc++)

Or libstdc++

3. C library (PDCLib?)

4. ABI (libc++abi)

Or libcxxrt, or libsupc++.
5. Unwinder (sort of part of libc++abi, or libgcc_s)

I assume that an unwinder is related to stack unwinding when an exception
is thrown. What does that require beyond what libc++abi supports?

Yes, and it depends on what kind of unwinding information your platform needs/expects. If it follows the Itainium Unwind ABI or you decide to go with SjLj exceptions, you should have an easier time porting the libc++abi one. If it is significantly different than one of those two (i.e. ARM EHABI, which we are just finishing up upstreaming) you'll have more.... 'fun'.

Jon