[Toybox] gcc vs llvm -static-libasan

[enh]

On Tue, Jul 9, 2024 at 3:06 PM Rob Landley <rob at landley.net> wrote:
>
> On 7/9/24 12:35, enh wrote:
> > On Tue, Jul 9, 2024 at 10:02 AM enh <enh at google.com> wrote:
> >> On Tue, Jul 9, 2024 at 8:47 AM Rob Landley <rob at landley.net> wrote:
> >>
> >> i'll forward this to the llvm asan folks anyway, in particular the
> >> "gcc and llvm use different flags" is the kind of papercut that i
> >> think both gcc and llvm have been trying harder to avoid lately.
> >
> > https://github.com/llvm/llvm-project/pull/98194 for that.
>
> Wunderbar. (I think it's related to the stroopwafel.)
>
> When does your AOSP toolchain update in the main build so I can commit/push a
> change using it for ASAN=1 builds without inconveniencing you?

i'm already all-hwasan all the time anyway, so you can literally do
that right now and i won't notice. (although i claim to also be "all
clang, all the time", and probably am on all my _personal_ machines,
i'm a lot less likely to fuck with the configuration on any work
machine, so i'm probably accidentally using gcc anyway whenever i just
clone toybox into /tmp for a quick poke at something.)

> > apparently your "static asan" request is even harder than i thought...
>
> Last time I tried setting up a container we wound up debugging stdin handling in
> bionic's _start code (although that _was_ because the laptop I was using at the
> time had an old processor throwing illegal instruction errors, so I needed to
> build a kernel and run it through qemu and used mkroot, which triggered some sad
> initramfs behavior in the kernel.)
>
> The current laptop seems to run the binaries so far. (I'm grinding through make
> tests even, just static build without ASAN enabled...)
>
> > the folks who actually know what they're talking about (because they
> > implemented all of these things), fully static asan isn't a thing ---
>
> It is for gcc/glibc, although I expect they're only implementing half the tests
> the LLVM guys have...
>
> > "bionic's hwasan support is a special well-integrated combination that
> > works in static binaries, but everything else relies on symbol
> > interposition and the presence of the dynamic loader".
> >
> > so my default knee-jerk "have you tried hwasan?" was closer to the
> > mark than i realized at the time :-)
>
> Does qemu-system-aarrcchh6644 emulate hwasan?

yes. (though at that point -- unless you're virtualizing on an M2
MacBook Air or something -- it's likely slower than asan :-) )

> If so, how do I get a dynamic
> bionic chroot of a reasonable size to boot under qemu to test binaries? (If the
> NDK doesn't have an extractable sysroot dir, does AOSP have some sort of "lunch
> shellprompt"?)

see the shell script i just posted the link to. all you really need is
/bin/linker64, /bin/mksh, /bin/toybox [and symlinks] and whatever
transitive closure of libraries that pulls in. we _should_ "just work"
wrt the tzdata you have on your box already; it's not really tested,
but certainly the intention is to support the "tree of tiny files"
you're used to as well as the "one big file with index" that Android
uses.

> Or should I stick with the glibc one once I can check that in? (Dynamic linked
> bionic would allow more of the utf-8 plumbing to work, and thus get tested by
> me, but I have to finish replacing -lcrypt with lib/crypt.c before "make
> defconfig" builds under bionic, so I'm busy here for a while yet...)

(note that for all the unicode stuff, you'll also need the icu .dat
file in your "chroot". i don't actually know what happens if you have
the icu .so but not the .so file --- whether it gives you a helpful
diagnostic/crashes/just falls back to new jersey english^W^W^Wthe C
locale.)

> Rob