[Toybox] __attribute__((__noreturn__)) vs _Noreturn

[Rob Landley]

On 5/14/22 11:56, Ivo van Poorten wrote:
> On Sat, 14 May 2022 04:31:24 -0500 Rob Landley <rob at landley.net> wrote:
>> On 5/11/22 11:55, Ivo van Poorten wrote:
>> > https://github.com/rui314/chibicc
>> 
>> Yeah, I saw your poke about that through the old qcc mailing list. :)
> 
> Haha, wasn't sure if it was still read, so I thought I'd post a link
> here, too. Wider audience, etc..
>  
>> kconfig/conf.c:38: static char nohelp_text[] = N_("Sorry, no help
>> available for this option yet.\n");
>>                     ^ expected ','
> 
> This looks like a cpp bug, assuming N_ is a macro. 

Yup, several other simple C compilers I tried had various cpp bugs, and more
than one didn't consider 'int a = 0 || "string";' to be a constant initializer
(but whatever the pointer for "string" is it CAN'T be NULL, and || returns 1 or
0 depending on whether its inputs are zero or nonzero, therefore...) See my
comment at the end of:

https://www.patreon.com/posts/building-toybox-66377238

(I would love to be able to link to the specific comment, but patreon doesn't
seem to have implemented that? You'd think when patreon raised its fees for new
creators they would have used the money to hire somebody, but they haven't
responded to vimeo exiting the video hosting business, still haven't fixed the
screen blanking bug, inexplicably handed half their market to onlyfans...)

(Huh, not "half": patreon pays out an average of $6.4 million/month so somewhere
under $100 million/year going through it, and onlyfans took in over $2 billion
in 2020. Meanwhile pornhub's annual revenue is $97 billion, about 5 times
prudetube's which pixelates out bikinis. Yup, humans continue to be hume.)

>> 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?
> 
> chibicc could work like tinycc, having several codegen-*.c, and compile
> separate binaries for each target. Looks like it now solely targets
> x86_64.

Working like tinycc would mean also having a linker. Instead it generates text
assembly and feeds it through an external as. (Which is a choice, but means that
tinycc in 100k lines of code could run a program, and chibicc can't. In fact
half the reason people ever used tinycc was because #!/usr/bin/tinycc -run at
the top of your C file, with chmod +x, meant you could execute your C source.)

>> 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...)
> 
> Probably. x86_64, arm64 and risc-v should cover most use cases.

I do not care about open Itanic, and am unlikely to start.

Meanwhile, open powerpc has cycled back around to relevance since Red Hat
reverse-bought IBM. They've been fairly quiet about it, but:

https://www.eejournal.com/article/ibm-gives-away-powerpc-goes-open-source/

https://hackaday.com/2020/08/28/open-hardware-laptop-built-on-power-pc-isa/

https://hardware.slashdot.org/story/21/07/10/0154220/libre-socs-open-hardware-180nm-asic-submitted-to-imec-for-fabrication

And so on, and so forth. Full 64 bit multi-issue speculative execution
instruction reordering song and dance, I'm told.

(And Jeff Dionne submitted a j-core mask to Google's sky130 fab earlier this
year, that's chugging along. He's being even quieter about it...)

>> 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?)
> 
> I remember. I have been "following" you for a while ;) Possibly
> from since around the time you forked tcc and got the BSD license
> permission from Bellard.

Sorry about the slow progress. There's more to do than I've had time for...

>> Do you think it's worth feeding the chibicc guy bug reports about
>> trying to build stuff with it?
> 
> I'm not sure. The github repo hasn't been updated in 17 months, and
> there is no book to be found yet.
> 
> But I found his earlier 2020 book. In Japanese:
> 
> https://www.sigbus.info/compilerbook
> 
> Perhaps one bug report to see if he's responsive?

It's a small and clean enough codebase somebody could theoretically fork it if
necessary. MIT license is reasonable. But one architecture, no assembler, no
linker... there's a todo list.

(I do NOT have the bandwidth, there's a reason I parked my tinycc fork. Toybox
and aboriginal linux were already two projects, and mkroot _needs_ to expand
into the space aboriginal linux used to do for toybox to have a proper
greenhouse to grow to full size in. Android's great but they mostly use what's
there and don't use what isn't. A system build environment absorbing new
packages makes _demands_.)

>> A chibicc/lld pair would be interesting (apparently the same guy
>> wrong both),
> 
> Yes. Only as would be missing (as as in cc/as/ld). You mentioned strip,
> nm, ... (objdump?) but those are not the first priority. Perhaps ld
> could even have (or already has?) an option that strip becomes (almost)
> obsolete?

A) strip isn't obsolete if build scripts call it,
B) it's a subset of objcopy which a lot more stuff calls (including the linux
kernel build making bzImage and friends).

Toybox already has a readelf. Both nm and objcopy/objdump theoretically share a
lot of code with that. (Modulo objdump -d being an architecture-specific reverse
assembler...)

By the way, it should be possible for strip and friends to autodetect the symbol
prefix. (Did you know that sh4 was implemented based on an ELF spec  that had
been run through a translator, and the code page switch turned _ into . which
they dutifully used as the symbol prefix in the hitachi toolchain, and if you
use an x86 strip on an sh4 binary it blindly assumes the first character of
symbols is always _ so it replaces the . with _ randomly and the ELF loader
can't parse the resulting binary because the symbol names don't match up? The
<strike>Aristocrats!</strike> Free Software Foundation!)

>> 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
> 
> Totally agree. I had classes from him back when Minix 2 was a thing,
> but we also got Minix 1 floppies for the Atari ST and MSDOS :) I think
> it was all about the book deal in the end.

Academics gotta publish to get tenure.

https://youtu.be/ukAkG6c_N4M

> Minix 3 was a step forward, as it was written from scratch and didn't
> suffer the license dependencies that Minix 2 still had, but it failed to
> really catch on. On the other hand, Intel apparently put it in their
> "spy" part of their CPUs ;)

Yeah, I saw the pdf wander by on lwn about trying to reflash that with Linux...

It's possible minix3's kernel could work as part of the 4 package
kernel/cmdline/libc/compiler build system, but I expect it would need as much
work as any of the tiny compilers to be actually load bearing. (I've had various
bsd kernels waved at me over the years too, 2.11bsd and netbsd come up a lot...)

The thing is, I'm trying to make toybox scale to the point it's not just part of
the simple base, but you can keep it in the final deployed system if you want
to. It's simple but ACTUALLY USABLE. You could say the same about musl-libc. But
none of the tiny kernel or tiny compiler variants I've looked at are more than
"this gets you past the Ken Thompson Trusting Trust audit, and then you replace
it with a big thingy".

(All that microkernel nonsense SHOULD have been about "here is the simple core
and here are the extensions that talk via a stable API to the base", instead of
"I'm going to spend all my time constructing, passing, and consuming messages to
myself while fiddling with hardware that kills the system dead if you get a PCI
range register set wrong or cause a DMA to the wrong place or screw up the page
tables or move the interrupt dispatch table out from under the scheduler or
accidentally block the timer interrupt and priority inversion isn't ANY of those
and you're just gonna gloss over locking entirely aren't you and technically
there's a way to ask the hardware to literally power off and if you REALLY want
to attack the system what you do is figure out how to disable the thermal
sensors/throttling before some big number crunching..." But sure, message
passing. Right.)

Rob