On Tue, Jul 9, 2024 at 3:06 PM Rob Landley <[email protected]> wrote: > > On 7/9/24 12:35, enh wrote: > > On Tue, Jul 9, 2024 at 10:02 AM enh <[email protected]> wrote: > >> On Tue, Jul 9, 2024 at 8:47 AM Rob Landley <[email protected]> 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 _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
