[Toybox] [PATCH] Android moved the scheduler policy functions in Q.

enh enh at google.com
Fri May 3 12:43:45 PDT 2019


On Fri, May 3, 2019 at 11:41 AM Rob Landley <rob at landley.net> wrote:
>
> On 5/2/19 12:37 PM, enh wrote:
> > On Thu, May 2, 2019 at 9:35 AM Rob Landley <rob at landley.net> wrote:
> >>
> >> On 5/1/19 5:40 PM, enh via Toybox wrote:
> >>> They're forwarded to libprocessgroup, but we may as well go straight to
> >>> the source since neither library is in the NDK anyway.
> >>>
> >>> This code is unfortunate because it means that even `toybox true` ends
> >>> up pulling in a JSON parser at runtime, because ps might call
> >>> get_sched_policy/get_sched_policy_name. I'll experiment with
> >>> dlopen-on-demand in portability.c and see whether the savings are
> >>> worthwhile, but for now at least use the current library directly so we
> >>> can save *one* dlopen!
> >>
> >> I'm as-needed in the linker but glibc defeated that by having librt pull in
> >> libpthread when clock_gettime() has been part of glibc proper since the 2.17
> >> release ~7 years ago.
> >
> > does as-needed actually help when you're built RELRO? certainly
> > Android does everything up front for RELRO (which has been mandatory
> > for years). i don't know what glibc does, but i do know that my linux
> > boxes are at least using partial RELRO these days.
>
> I have no idea, compilers and optimization are moving targets, and I just
> updated off of Ubuntu April 2014 edition last month. :)
>
> That said, a V=1 build for defconfig on devuan has:
>
>   -Wl,--as-needed -lutil -lcrypt -lm -lresolv -lz
>
> resulting in:
>
> $ ldd toybox
>         linux-vdso.so.1
>         libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1
>         libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
>         /lib64/ld-linux-x86-64.so.2
>
> So it's dropping out zlib, libresolv, libm, and libutil since it didn't
> compile-time resolve anything out of them, so with the default flags at least it
> still works?
>
> Lemme look up what relro does...
>
> https://www.redhat.com/en/blog/hardening-elf-binaries-using-relocation-read-only-relro
>
> Ah. It's the opposite of lazy binding, mark PLT and GOT read only once they've
> been resolved. Yeah, pretty obvious. That should mostly just be a question for
> the dynamic linker, not the compile-time linker, I'd think? I don't see why
> --as-needed at compile time would stop working, since that's _resolved_ at
> compile time. (It says don't generate the ELF references for libraries it didn't
> need any symbols from.)

yeah, i realized that after hitting send yesterday, but forgot to come
back. --as-needed isn't relevant for my case at all.

> >> Meanwhile, Android seem to have reinvented the microkernel again and turned
> >> everything in the world into message passing:
> >>
> >> https://security.googleblog.com/2019/03/open-sourcing-sandboxed-api.html
> >
> > (fwiw, i think that's Chrome. certainly nothing to do with us.)
>
> Oh good. (I'd eventually like to make _that_ support a development environment
> too, but one bite of the elephant at a time...)
>
> Rob



More information about the Toybox mailing list