RFC: Add OsUnknown as a target operating system

[bharrisau]

cc: rust-lang/rust#12841

[alexcrichton]

Can you format lines to a maximum of 80 characters in width?

[bharrisau]

Teach me to think I could do the whole thing in Github; only has soft-wrap and no-wrap (without 78/80 char indicator).

[alexcrichton]

Having an unknown OS seems like something that shouldn't be a new thing. Has this been explored before in other compilers/languages? I'm concerned that if LLVM doesn't understand an unknown OS that the codegen will be difficult to get right.

As you mentioned in the unresolved questions section, this does indeed sound a lot like a clone of linux not built on libc but rather built on another library, specifically newlib. I would be tempted to explore the possibility of a newlib-based target before adding an unknown OS target.

Just for reference, here's a list of OS-specific things which we do today which I can think of:

• I/O
• rust task pointer storage
• stack bounds
• #[thread_local]
• #[linkage]
• spawning threads
• std::os

One thing I'm really worried about is the segmented stack prologue generated by LLVM. There's really no way to generate it unless you're targeting a specific OS

[bharrisau]

I'll have to do the 80 char thing later tonight. I was doing it in Github but realised that it wasn't even using a monospace font.

I chose 'unknown' because it is the LLVM standard for... well... unknown. To tackle the list above

• I/O
  • Newlib provides C99 so it allows for read/write/open/etc. The porting layer needs to provide the 17-18 functions that handle talking to the OS or hardware. So 'unknown' is OS agnostic for I/O
• rust task pointer storage
  • Not sure what this is (obviously not just TLS?)
• stack bounds
  • This is in rt/arch/X/record_sp.S (for ARM and MIPS anyway). There are two function that need to be implemented (record_sp_limit and get_sp_limit). Linked to the segmented-stack issue.
• thread_local
  • Pthreads is 'supported' by newlib, but not implemented (needs to be implemented by the OS). gcc/linker handles this, so the complaints will come from there (so it is still a problem, but from my point of view, embedded wont use threads in most cases)
• linkage
  • Dynamic is out, is the rest just going to sit with the compiler?
• threads
  • As above for thread_local
• std::os
  • Would need to see what is essential and what is optional. Essential is then a list of symbols that the implementer needs to provide, and optional is handled by weak symbols else fail.

The segmented-stack is related to rust-lang/llvm#4. Thumb arch support was added, but this was done in an OS agnostic way. The implementation is required to provide the STACK_LIMIT symbol, and then provide compatible rt/arch/X/record_sp.S functions that set/get using this.

So really the target is thumb-C99/C++/pthreads-*.

Edit: Looking through os, major areas are filesystem (CWD, HOME, etc. mandatory if used), environment (covered by newlib), call args (optional otherwise empty), and memory map.

[emberian]

@alexcrichton you can target no-OS by using, for example i686-elf or x86_64-elf.

[emberian]

(I think)

[bharrisau]

Not specifying an OS to LLVM (or specifying an unimplemented OS) drops to the default OS UnknownOS (https://github.com/llvm-mirror/llvm/blob/master/lib/Support/Triple.cpp#L116).

[bharrisau]

If someone wants to give a "thumbs up" that this is the right way to go for handling embedded/portability targets I'll continue to see how much of the above list "just works". If I'm going down the totally wrong track let me know.

Based on the naming from rust-lang/rust#11828, I'm aiming for features from prim, libc and anything else that just works.

A possible alternative is to be able to build libstd but explicitly disable dynamic linking. So hide the crate-type=dylib and change the rtdeps to not include libdl.

[alexcrichton]

rust task pointer storage

This is currently in TLS, we may put this in one of a few locations though.

thread_local

This is not just pthreads TLS, but also the #[thread_local] attribute which has to do with emitting information about the global into the object file's header. This often also has runtime support with symbols that need to get resolved.

segmented stacks

I fear that this is getting brushed off too easily. LLVM fundamentally cannot generate code for segmented stacks with an "unknown os". The prologue is highly dependent on the platform that it's running on. For example, LLVM currently fails with the target x86_64-elf with LLVM ERROR: Segmented stacks not supported on this platform.

This RFC doesn't seem to mention what would happen with segmented stacks on an unknown OS (this includes runtime support for unknown OSes).

This also ties in with my concern about the stack bounds. This isn't just a problem of "implement two functions and that's it", the two functions just can't be implemented for triples where you don't know the OS because you don't know what's available to you.

In general, it sounds like an "unknown os" is a concept in a target triple, so I'm ok supporting generating code for it, but I don't feel that this RFC has been fleshed out enough. Without disabling segmented stacks (which this RFC does not mention), I'm having trouble seeing the path forward.

[bharrisau]

Thanks. As I said, at the moment the only sane arch for unknown is thumb
(not sure if something like arm-win32-androideabi is a sane triple). But as
long as I'm on the right track I'll keep at it.

I'll flesh the RFC out some more by trying to get an idea of what features
are linked to the OS. I have an idea for handling custom preludes if it
isn't sufficient to limit support to just thumb-unknown-eabi. Some of this
stuff I've never bothered to get a good understanding for as I never use it
in an embedded context (e.g. thread local) so I'm trying to keep up.
On 18/03/2014 1:28 am, "Alex Crichton" [email protected] wrote:

rust task pointer storage

This is currently in TLS, we may put this in one of a few locations though.

thread_local

This is not just pthreads TLS, but also the #[thread_local] attribute
which has to do with emitting information about the global into the object
file's header. This often also has runtime support with symbols that need
to get resolved.

segmented stacks

I fear that this is getting brushed off too easily. LLVM fundamentally
cannot generate code for segmented stacks with an "unknown os". The
prologue is highly dependent on the platform that it's running on. For
example, LLVM currently fails with the target x86_64-elf with LLVM ERROR:
Segmented stacks not supported on this platform.

This RFC doesn't seem to mention what would happen with segmented stacks
on an unknown OS (this includes runtime support for unknown OSes).

This also ties in with my concern about the stack bounds. This isn't just
a problem of "implement two functions and that's it", the two functions
just can't be implemented for triples where you don't know the OS because
you don't know what's available to you.

In general, it sounds like an "unknown os" is a concept in a target
triple, so I'm ok supporting generating code for it, but I don't feel that
this RFC has been fleshed out enough. Without disabling segmented stacks
(which this RFC does not mention), I'm having trouble seeing the path
forward.

Reply to this email directly or view it on GitHubhttps://github.com//pull/7#issuecomment-37844646
.

[bharrisau]

I've fallen behind on this rfc, most of my spare time has been working out what changes are needed to build well. With #40 landing I think it's best to wait to see if this is still necessary (may still be wanting someway to disable building dylibs).

[alexcrichton]

I agree, it sounds like we should wait for the dust to settle with libcore before moving forward with this RFC. I'm going to close this for now, but we can reopen if the time is ripe later on.