[Toybox] __attribute__((__noreturn__)) vs _Noreturn

[Rob Landley]

On 5/11/22 11:55, Ivo van Poorten wrote:
> On Wed, 11 May 2022 09:04:01 -0700 enh via Toybox
> <toybox at lists.landley.net> wrote:
>> there's plenty of C++ in the GNU stuff these days; that's orthogonal.
> 
> Yes. gcc cannot compile itself anymore without g++.

I've noticed. https://twitter.com/landley/status/983057803223891969

> chibicc looks promising.
> 
> https://github.com/rui314/chibicc

Yeah, I saw your poke about that through the old qcc mailing list. :)

$ CC=chibicc HOSTCC=$CC make defconfig
chibicc -o kconfig/conf kconfig/conf.c kconfig/zconf.tab.c -DKBUILD_NO_NLS=1 \
	-DPROJECT_NAME=\"ToyBox\"
kconfig/conf.c:38: static char nohelp_text[] = N_("Sorry, no help available for
this option yet.\n");

                    ^ expected ','
make: *** [kconfig/Makefile:73: kconfig/conf] Error 1
$ make distclean defconfig
...
$ CC=chibicc HOSTCC=$CC make V=1 CPUS=1
scripts/make.sh
Generate headers from toys/*/*.c...
generated/newtoys.h Which C files to build...
Library probe............
Make generated/config.h from .config.
/home/landley/toybox/pending/chibicc/chibicc scripts/mkflags.c -o generated/mkflags
generated/flags.h generated/globals.h
chibicc scripts/mktags.c -o generated/mktags
generated/tags.h /home/landley/toybox/pending/chibicc/chibicc
scripts/config2help.c -o generated/config2help
generated/help.h
Compile toybox
chibicc -Wall -Wundef -Wno-char-subscripts -Werror=implicit-function-declaration
-funsigned-char -I . -Os -ffunction-sections -fdata-sections
-fno-asynchronous-unwind-tables -fno-strict-aliasing -DTOYBOX_VERSION="0.8.0" -c
lib/args.c -o generated/obj/lib_args.o
unknown argument: -funsigned-char
make: *** [Makefile:19: toybox] Error 1

There are some todo items, it seems. (Also, what targets does it output code
for? Hmmm, codegen.c looks like it's hardwired to x86? My whole qcc idea was to
glue qemu's tcg to the tinycc front end to get all the targets qemu supports,
but these days I think that's waaaaay overkill...)

Also, this is a compiler but not an assembler or linker. Or strip, nm...

  http://landley.net/hg/qcc/file/tip/todo/commands.txt
  http://landley.net/hg/qcc/file/tip/todo/todo.txt

(My tinycc rewrite was going to make a multiplexer out of it so it ran as the
appropriate tool when called by the appropriate name. Alas, stopped working on
that in something like 2008?)

> A book and all.
> 
> But so did pcc (haven't heard much about it lately) and tinycc (which
> is a mess with its mob branch, and it licensing).

I forked tinycc before that whole "mob branch" thing happened, and still have
that old fork:

  https://landley.net/code/qcc

I got permission from Fabrice Bellard to use his code under a BSD license (which
I'm interpreting to mean 0BSD), although I have to cull other developers'
patches from the result. I did the basic triage work once upon a time:

  http://landley.net/hg/qcc/file/tip/todo/relicense.txt

But I've been spread too thin and just haven't had TIME to work on that.

There are 4 packages to establish a base: 1) kernel, libc, cmdline, compiler.
The compiler has to be able to successfully build all four in order to get past
the circular dependency part into build-under-yourself territory.

It's theoretically possible to substitute a simpler kernel than linux (bsd or
xv6 or a forward-ported linux 2.0 before it hulked out), but I haven't looked
too deeply at what's available there. The https://midipix.org/ guys got musl to
work on the windows native API, and the BSD guys implemented a whole "linux
emulation layer" (https://docs.freebsd.org/en/articles/linux-emulation/) so in
theory reimplementing the API is a known-ish problem. (And yes /proc and /sys
are part of said API at the moment, Linux provides no other obvious way to get
access to that information...)

Once you've got a working base booted under qemu (or on real hardware; alas
raspberry pi is TERRIBLE for this both because it loads its proprietary bios
binaries from the sd card and because its serial console is on two random gpio
pins in the hat connector rather than somewhere SANE like the USB connection
that powers the board)...

Anyway, the next thing you want to be sure the tiny/simple compiler builds is
https://github.com/JuliaComputingOSS/llvm-cbe so you can build a modern full
compiler as necessary (and thus compile all the crap written in c++ that people
tend to want; getting llvm compiled to C by that is left as an exercise for the
reader, I.E. Waaaaay down on my todo list).

Then it's just "bootstrap your way through Linux From Scratch and then Beyond
Linux From Scratch" like I did for busybox back with
http://landley.net/aboriginal/control-images/

I would be absolutely thrilled if somebody ELSE did this, but...

https://lists.linuxfoundation.org/pipermail/celinux-dev/2010-January/000292.html

Alas, Howard Aiken was right:

https://www.inc.com/greg-satell/heres-why-you-shouldnt-worry-about-people-stealing.html

Do you think it's worth feeding the chibicc guy bug reports about trying to
build stuff with it? A chibicc/lld pair would be interesting (apparently the
same guy wrong both), but this STILL hits the problem that llvm's libgcc
replacement is apocalyptically bad:

  https://landley.net/notes-2021.html#28-07-2021

(You wouldn't think this was hard! And yet...)

The main reason Linux ate Minix is Andrew Tanenbaum wanted a teaching tool, and
rejected patches that complicated his simple/clear project with real world stuff
like a network stack or overlapping I/O and interrupts. (Well, in his case he
took zero outside contributions for IP reasons to do with his textbook contract,
see https://www.oreilly.com/openbook/opensources/book/appa.html) This built up a
backlog of patch pressure that grounded out through Linus's toy kernel and took
it from 0.0.1 to 0.95 in a few months with a dev community of dozens of people
migrating from comp.os.minix to linux.activists back in
https://landley.net/history/mirror/linux/1991.html and
https://landley.net/history/mirror/linux/1992.html. What was unique about Linus
was he TOOK PATCHES, merged them, and got out new releases quickly. This let him
not just harness the work of other developers, but they influenced the project's
design goals. (He didn't need swap, but implemented it because somebody ELSE
needed it. Linus took direction based on what his contributors thought was
important enough for them to work on, test, and submit patches to him.)

The big problem with https://pdos.csail.mit.edu/6.828/2012/xv6.html is its
definition of "teaching OS" isn't a full Posix environment, and doesn't
implement stuff like mount or mmap that you kind of need to run gcc. (It's not
at the "bootstrap up to big system from within this one" stage; what's there is
not sufficiently capable to host a real extensible build environment.) Students
who take the class and work through the textbook regularly extend it to turn it
IN to a real posix environment (https://github.com/NewbiZ/xv6 and
https://github.com/artem179/xv6 and so on), but none of that ever goes back
upstream because "teaching tool", and there's no cannonical extended version the
extenders all agree on, and if they DID there's no guarantee they'd agree on a
good STOPPING point rather than extending it into another linux-like hairball...

Sigh, I had a whole talk about this, "the prototype and the fan club". I gave it
at Flourish in Chicago, but the video they posted is missing the first 30
seconds (basically establishing that somebody creates a prototype other people
find interesting, and a fan club forms around it), and the sound is garbled for
the next 30 seconds (although it clears up after that).

  https://landley.net/talks/prototypeandfanclub.flv
  https://landley.net/talks/flourish-2010.txt

I keep meaning to redo that talk. Maybe for youtube? I keep thinking "this is
from 12 years ago, surely it's obvious to everyone by now?"

Rob