According to the linux waitid manpage, the value of wstatus is
unspecified if wait() returns 0, so we should not assume that any
value it holds is correct (including the exit code).
This is only applicable to the Lagom build.
I decided to play around with trying to run Serenity in VirtualBox.
It crashed WindowServer with a beautiful array of multi-color
flashing letters :^)
Skipping getting side-tracked seeing that it chose MBVGA in the
serial debug and trying to debug why it caused such a display,
I finally checked BXVGA.
While find_framebuffer_address checks for VBoxVGA, init_stage2 didn't.
Whoops!
Some of the remaining instructions have different behavior for
register and non-register ops. Since we already have the
two-level flags tables, model this by setting all handlers in
the two-level table to the register op handler, while the
first-level flags table stores the action for the non-reg handler.
This file was formerly named `Libraries/LibCore/puff.c` and it was not
checked by `check-style.sh` because it only checks .h and .cpp files.
Since this file was not written by us, we shouldn't check its style.
This file was also causing our Travis builds to fail.
Now that we don't keep a C compiler around in the toolchain (to save
space) we can't have .c files in the build.
This reminds me that #362 exists and we should fix that at some point.
Empirically, every single push or PR has to download *and then upload*
about 3.6 GiB of "cache stuff", which takes up about 400 seconds:
https://travis-ci.com/github/SerenityOS/serenity/builds/177500795
On every single push/PR! No matter what!
Those 3.6 GB consist of:
- 3.2 GB Toolchain cache (around 260 MB per compressed item)
- 0.4 GB ccache, but is capped at 0.5 GB: https://travis-ci.com/github/BenWiederhake/serenity/builds/177528549
- (And 200 KB for some weird debian package? Dunno.)
Investigating in the size, the Toolchain consists mostly of *DEBUG SYMBOLS IN
THE COMPILER BINARIES* which comically misses the point. If we ever run into
compiler crashes, any stacktrace would be lost anyway as soon as the Travis VM
shuts down. Furthermore, Travis will only ever compile Serenity itself, and
Serenity forbids C in it's Contribution Guidelines. That's another 20 MB we
don't need to cache.
Stripping the binaries and deleting the C compiler reduces the uncompressed size
from 1200 MB down to 220 MB. The compressed size gets reduced from 260 MB to 70MB.
That's a reduction of 73%.
It'll take a while until the 'old' toolchains get deleted.
I guess it'll take less than a week.
From that point onward, the Travis cache will be 1.2 GB, consisting of:
- 0.7 GB Toolchain cache
- 0.5 GB ccache
- (And that weird 200 KB deb file)
If network speeds are linear, then this should reduce the "cache network
overhead time" from about 400 seconds to about 120 seconds.
tl;dr: Strip unnecessary debug infos, delete an unused files, and speed
everything up by two minutes. (Both Toolchain cache hits and Toolchain rebuilds!)
Uploading the cache takes several minutes. This gives us a handy way to tell
which parts the worst culprits are.
The Toolchain cache seems to be the worst offender by far, because the binary
size nearly doubled when we upgraded from gcc9 to gcc10.
We were masking the fragment offset bits incorrectly in the IPv4 header
sent out with fragments. This worked up to ~32KB but after that, things
would get very confused. :^)
Const pointers into the DOM was a nice idea, but in practice, there are
too many situations where the layout tree wants to some non-const thing
to the DOM.
ModularFunctions::random_number calls into AK::fill_with_random calls (on
Serenity) into arc4random_buf calls into Process::sys calls into
get_good_random_bytes, which is cryptographically secure.
Some of these don't just use the REG bits of the mod/rm byte
as slashes, but also the R/M bits to have up to 9 different
instructions per opcode/slash combination (1 opcode requires
that MOD is != 11, the other 8 have MODE == 11).
This is done by making the slashes table two levels deep for
these cases.
Some of this is cosmetic (e.g "FST st0" has no effect already,
but its bit pattern gets disassembled as "FNOP"), but for
most uses it isn't.
FSTENV and FSTCW have an extraordinary 0x9b prefix. This is
not yet handled in this patch.
