daedaleanai/libsupcxx

A bare metal port of the GNU ISO C++ library

libsupcxx's Issues

Shell status code not always correctly set. (Test08 fails)

Test08 fails, in that it returns a non-zero shell status code (1 on my machine).

The main() function calls std::exit(0), so the status code should be 0. (Just as a note -- the call to std::exit(0) is redundant in the test, since dropping off the end of main is the same as returning 0, which is the same as exit(0)).

dbt run "//libsupcxx/tests/Test08" cc-toolchain=linux-x86_64-libsupcxx

Running libsupcxx/tests/Test08:
Constructing global object
glibcxx datestamp: 20180726
glibcxx release: 8
sizeof(std::size_t): 8
float eval method: 0
ULLONG_MAX: 18446744073709551615
__alignas_is_defined: 1
printArgs(5, 1, 2, 3, 4, 5)
__bool_true_false_are_defined: 1
sizeof(std::uint8_t): 1
At exit function called
Destructing global object
FAILED: libsupcxx/tests/Test08#run

Return code from main ignored

The return code from main using libsupcxx is not the same as calling exit, at least in linux-x86_64-libsupcxx . Specifically, sys::exit(1) (which calls the C function exit(1)) causes a shell exit status of 1, whereas "return 1;" from an initial call to main leads to a shell exit status of 0.

Note, the C standard says:
5.1.2.2.3 Program termination

1. If the return type of the main function is a type compatible with int, a return from the
   initial call to the main function is equivalent to calling the exit function with the value
   returned by the main function as its argument.

gcc toolchain BUILD.go served from a .tar.gz on storage.googleapis.com

We serve x86_64-elf-gcc from storage.googleapis.com. That's fine for the binaries (and I guess something like this is necessary to avoid the push limits of github).

But we also have BUILD.go in there, which specifies the toolchain.

I feel like that file should be in version control (ie: github). It's unlikely we want to edit gcc source files, but we do want to occasionally edit the BUILD.go. Right now apart from being a bit of a pain, the process for changing BUILD.go is very unclear.

Could we have a github repo per toolchain with just the BUILD.go file, and a dependency on the binaries on storage.googleapis?
This would also make specifying a version of the toolchain easier as we can depend on git branches and tags like for other versioned things.

Test05 is flawed

Test05 currently fails with a crash.

The comments and print statement suggest that the expected behavior is as it is, but the behavior (as the comments also suggest) is undefined behavior.

There's several problems with this test:

1. The test fails, even though the behavior is as expected.
2. It's undefined behavior, so there is no guarantee what the test does.
3. Even if the runtime is supposed to support specific behavior when one tries to recursively init a local static, any code that contains this construct exhibits undefined behavior and is therefore already faulty.

Here's an example running the test:

$ dbt run "//libsupcxx/tests/Test05" cc-toolchain=linux-x86_64-libsupcxx

Running libsupcxx/tests/Test05:
Getting the meaning of life!
Computing the meaning of life!
Answer to the Ultimate Question of Life, the Universe, and Everything: 42
Getting the meaning of life!
Answer to the Ultimate Question of Life, the Universe, and Everything: 42
recursiveInit(0)!
recursiveInit(1)!
FAILED: libsupcxx/tests/Test05#run

Unwind stack on failure

A basic version could just return the raw return addresses. It can be expanded by reading the symbol table and printing the function names.

io/ is a hidden dependency of boot/

boot/raspi3 and boot/linux-x86_64 use io/string.hh/cc for standard C string functions. This dependency shouldn't exist, as at the moment io is not automatically linked, and it's probably best to keep standard C string functions in libsupcxx, which is always linked.

x86_64 toolchain has ArchName "i386"

It's probably not a big deal, but the toolchain registered by x86_64-elf-gcc has the field ArchName set to "i386".

I would expect it should be "x86_64".