[Toybox] [PATCH] Addition of the 'g' command to vi.c

[Rob Landley]

On 10/10/23 12:52, enh wrote:
>> In theory ASAN should be able to spot that one! In practice, if it's a local
>> variable on the stack, not so much.
> 
> you can add `-ftrivial-auto-var-init=pattern` to your CFLAGS.

$ CFLAGS="-ftrivial-auto-var-init=pattern" ASAN=1 make clean defconfig tests
...
cc: error: unrecognized command line option '-ftrivial-auto-var-init=pattern'

The host compiler is gcc 8.3.

$ CROSS_COMPILE=ccc/x86_64-linux-musl-cross/bin/x86_64-linux-musl-
CFLAGS="-ftrivial-auto-var-init=pattern" ASAN=1 make clean defconfig tests
...
x86_64-linux-musl-cc: error: unrecognized command-line option
'-ftrivial-auto-var-init=pattern'

The cross compiler is gcc 11.2, Looks like this is an llvm-only thing.

Which I'm happy to test, but I need to do the next cleanup pass to get "make
tests" to pass building with the NDK. Or maybe the next round of wrestling with
the llvm-hexagon compiler, but running the test suite under qemu applicatioon
emulation is creepy and they still haven't published a full qemu-system-hexagon
for the comet board yet:

https://www.openwall.com/lists/musl/2023/09/27/4#:~:text=qemu-system-hexagon

Nobody else HASN'T got a gcc+glibc for their architecture (modulo a couple
really tiny chips stuck on the corpse of uClibc, but they were still gcc), so
they don't put nearly as much effort into maintaining llvm toolchains, let alone
llvm+musl ones. (I miss http://ellcc.org/ but it was last updated in 2017 and I
worked with its maintainer at JCI in 2018, and that job kept him WAY too busy to
work on ellcc. I _did_ explain to him why extracting all the source packages and
checking everything in to one big source control repository with your own
changes on top of the external files you'd checked in was NOT IDEAL, but he
never got around to redoing it...)

> (Android
> globally always uses -ftrivial-auto-var-init=zero because,
> surprisingly, it has better security properties than pattern. it's
> also better for code size etc.)

Sounds interesting, but I have no context to understand why you'd make what
decisions here. (The pattern is poisoning with a known value? And the other one
either disables the init or initializes it with zero? I thought the OS already
initialized freshly allocated memory with zeroes. Whatever DID happen with the
zero page, anyway? They stopped it from being an actual page with a reference
count way back when because A) there was contention for the counter, B) the
counter managed to wrap and free the page on some enormous system, which was
Suddenly Very Bad. But that was YEARS ago, before most of the huge page work I
think? Mel Gorman still seems to be around, he acked a patch in August, so I
assume it's all being reasonably managed, but beats me what they're up to...)

Anyway, I was thinking more like whatever caused commit 472599b99bec to ls. In
theory there's a tool that gets mad about reading from memory nothing ever wrote
to. Maybe it was valgrind? I don't want to run it _every_ time, but the
occasional pass might be interesting...

Rob