Discussion:
toybox and NDK sitrep
Add Reply
enh
2017-04-28 22:31:59 UTC
Reply
Permalink
Raw Message
since rob asked on some other thread earlier this week...

NDK r15beta2 should hopefully ship in time for I/O in a couple of weeks, so
i had a quick go at building toybox out of the box with the latest bits...

$ ./android-ndk-r15-beta2/build/tools/make_standalone_toolchain.py
--unified-headers --arch arm64 --api 24 --install-dir
/tmp/n-standalone-toolchain
$ git clone https://github.com/landley/toybox.git
$ cd toybox
$ CC=clang
CROSS_COMPILE=/tmp/n-standalone-toolchain/bin/aarch64-linux-android- make
defconfig
$ CC=clang
CROSS_COMPILE=/tmp/n-standalone-toolchain/bin/aarch64-linux-android- make

i've attached one patch to make mkpasswd not part of the "defconfig" for
Android, since (a) we don't have passwd and (b) we don't have crypt(3). so
it wouldn't be any use and you can't build it anyway.

i've attached another patch to add liblog to the list of probed libraries
so that toybox actually links okay.

with that there's only one problem left (ignoring compiler warnings, and
the fact that selinux and boringssl aren't part of the NDK so you'll be
without working versions of any of the selinux stuff or fast versions of
the hash stuff) --- there is no public API for the <cutils/sched_policy.h>,
so that still won't build out of the box.

(this was a useful exercise because it showed that <scsi/sg.h> was still
missing from the NDK, so that bug should finally be fixed for real this
time.)
--
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.
Rob Landley
2017-04-30 07:58:32 UTC
Reply
Permalink
Raw Message
Post by enh
since rob asked on some other thread earlier this week...
NDK r15beta2 should hopefully ship in time for I/O in a couple of weeks,
so i had a quick go at building toybox out of the box with the latest
bits...
Yay!

In other test harness news, I've put a lot of work into
https://github.com/landley/mkroot in the past week or so (simple
musl-libc test environment booting under qemu), and if you run the
mcm-buildall.sh script against
https://github.com/richfelker/musl-cross-make and then do something like

CROSS_COMPILE=~/musl-cross-make/output/aarch64-linux-musleabi-cross/bin/aarch64-linux-musleabi-
./mkroot.sh dropbear kernel

If it works you can then cd output/aarch64" and ./qemu-aarch64.sh and it
should boot you into a little emulated system.

I haven't got the whole https://landley.net/aboriginal/control-images
infrastructure reproduced yet, but I'm working on it.

I'd love to point CROSS_COMPILE at the NDK toolchains and try to get
those to work too. (Although the main reason I can use musl-cross-make
is I made puppy eyes at Rich to provide _native_ compilers, so my little
emulated environment can natively build stuff in the emulator. I need to
write and check in a module/distcc for mkroot so I can do the distcc
trick from http://landley.net/aboriginal/about.html and I see qemu
thinks it's grown multi-threaded SMP support, which might actually make
use of SMP on the host. I should poke at it, the single-cpu emulator
could only keep about 3 distcc slaves running on the host and even I've
got an 8-way SMP system...)
Post by enh
$ ./android-ndk-r15-beta2/build/tools/make_standalone_toolchain.py
--unified-headers --arch arm64 --api 24 --install-dir
/tmp/n-standalone-toolchain
Is there somewhere I can download ndk snapshots from?
https://developer.android.com/ndk/downloads/index.html just has beta 1...
Post by enh
$ git clone https://github.com/landley/toybox.git
$ cd toybox
$ CC=clang
CROSS_COMPILE=/tmp/n-standalone-toolchain/bin/aarch64-linux-android-
make defconfig
$ CC=clang
CROSS_COMPILE=/tmp/n-standalone-toolchain/bin/aarch64-linux-android- make
i've attached one patch to make mkpasswd not part of the "defconfig" for
Android, since (a) we don't have passwd and (b) we don't have crypt(3).
so it wouldn't be any use and you can't build it anyway.
i've attached another patch to add liblog to the list of probed
libraries so that toybox actually links okay.
Applied both, although I had to fix up the second so it installed on top
of your -libz patch.
Post by enh
with that there's only one problem left (ignoring compiler warnings, and
the fact that selinux and boringssl aren't part of the NDK so you'll be
without working versions of any of the selinux stuff or fast versions of
Out of curiosity, why not?
Post by enh
the hash stuff) --- there is no public API for the
<cutils/sched_policy.h>, so that still won't build out of the box.
I should add a compile time probe for that... try now?
Post by enh
(this was a useful exercise because it showed that <scsi/sg.h> was still
missing from the NDK, so that bug should finally be fixed for real this
time.)
Yay!

Rob
enh
2017-05-05 22:49:11 UTC
Reply
Permalink
Raw Message
Post by Rob Landley
Post by enh
since rob asked on some other thread earlier this week...
NDK r15beta2 should hopefully ship in time for I/O in a couple of weeks,
so i had a quick go at building toybox out of the box with the latest
bits...
Yay!
In other test harness news, I've put a lot of work into
https://github.com/landley/mkroot in the past week or so (simple
musl-libc test environment booting under qemu), and if you run the
mcm-buildall.sh script against
https://github.com/richfelker/musl-cross-make and then do something like
CROSS_COMPILE=~/musl-cross-make/output/aarch64-linux-musleab
i-cross/bin/aarch64-linux-musleabi-
./mkroot.sh dropbear kernel
If it works you can then cd output/aarch64" and ./qemu-aarch64.sh and it
should boot you into a little emulated system.
I haven't got the whole https://landley.net/aboriginal/control-images
infrastructure reproduced yet, but I'm working on it.
I'd love to point CROSS_COMPILE at the NDK toolchains and try to get
those to work too. (Although the main reason I can use musl-cross-make
is I made puppy eyes at Rich to provide _native_ compilers, so my little
emulated environment can natively build stuff in the emulator. I need to
write and check in a module/distcc for mkroot so I can do the distcc
trick from http://landley.net/aboriginal/about.html and I see qemu
thinks it's grown multi-threaded SMP support, which might actually make
use of SMP on the host. I should poke at it, the single-cpu emulator
could only keep about 3 distcc slaves running on the host and even I've
got an 8-way SMP system...)
Post by enh
$ ./android-ndk-r15-beta2/build/tools/make_standalone_toolchain.py
--unified-headers --arch arm64 --api 24 --install-dir
/tmp/n-standalone-toolchain
Is there somewhere I can download ndk snapshots from?
https://developer.android.com/ndk/downloads/index.html just has beta 1...
yeah, it'll be there when we actually release beta2, but until then you'll
have to get it from the usual [continuous builds](https://android.
googlesource.com/platform/ndk/+/master/docs/ContinuousBuilds.md).

either master or ndk-r15-release should be fine; they're more or less
identical right now.
Post by Rob Landley
Post by enh
$ git clone https://github.com/landley/toybox.git
$ cd toybox
$ CC=clang
CROSS_COMPILE=/tmp/n-standalone-toolchain/bin/aarch64-linux-android-
make defconfig
$ CC=clang
CROSS_COMPILE=/tmp/n-standalone-toolchain/bin/aarch64-linux-android-
make
Post by enh
i've attached one patch to make mkpasswd not part of the "defconfig" for
Android, since (a) we don't have passwd and (b) we don't have crypt(3).
so it wouldn't be any use and you can't build it anyway.
i've attached another patch to add liblog to the list of probed
libraries so that toybox actually links okay.
Applied both, although I had to fix up the second so it installed on top
of your -libz patch.
Post by enh
with that there's only one problem left (ignoring compiler warnings, and
the fact that selinux and boringssl aren't part of the NDK so you'll be
without working versions of any of the selinux stuff or fast versions of
Out of curiosity, why not?
in the literal sense: because the NDK has to guarantee ABI stability (since
your app might end up running on anything from Gingerbread to Nougat), and
those aren't under our control.

in the "why isn't it trivial to just say 'my app needs boringssl or
whatever, just build it and include it'?" sense: because the NDK has both
too many and too few build systems, and there's no good way to make this
work for all of them (plus whatever else you happen to be using).
Post by Rob Landley
the hash stuff) --- there is no public API for the
Post by enh
<cutils/sched_policy.h>, so that still won't build out of the box.
I should add a compile time probe for that... try now?
yep, works out of the box for me with arm and aarch64.

for this no-selinux/no-smack configuration, the compiler is confused by
lsm_context and incorrectly thinks that `result` can use used
uninitialized. this shuts it up (which you might want to do because it's a
super spammy warning by virtue of coming from a header file):

diff --git a/lib/lsm.h b/lib/lsm.h
index e21d424..005e1f6 100644
--- a/lib/lsm.h
+++ b/lib/lsm.h
@@ -55,7 +55,7 @@ static inline char *lsm_name(void)
static inline char *lsm_context(void)
{
int ok = 0;
- char *result;
+ char *result = NULL;

if (CFG_TOYBOX_SMACK) ok = smack_new_label_from_self(&result) > 0;
else ok = getcon(&result) == 0;




there's one other warning from ftpget.c which AOSP doesn't normally build:

toys/net/ftpget.c:140:9: warning: variable 'port' is used uninitialized
whenever 'if' condition is false [-Wsometimes-uninitialized]
if (rc==227) for (s = toybuf; (s = strchr(s, ',')); s++) {
^~~~~~~
toys/net/ftpget.c:149:31: note: uninitialized use occurs here
si6.sin6_port = SWAP_BE16(port); // same field size/offset for v4 and v6
^~~~
./lib/portability.h:202:31: note: expanded from macro 'SWAP_BE16'
#define SWAP_BE16(x) bswap_16(x)
^
/tmp/n-standalone-toolchain-arm/bin/../sysroot/usr/include/byteswap.h:35:30:
note: expanded from macro 'bswap_16'
#define bswap_16(x) __swap16(x)
^
toys/net/ftpget.c:140:5: note: remove the 'if' if its condition is always
true
if (rc==227) for (s = toybuf; (s = strchr(s, ',')); s++) {
^~~~~~~~~~~~~
toys/net/ftpget.c:96:23: note: initialize the variable 'port' to silence
this warning
int rc, ii = 1, port;
^
= 0

haven't looked in to that.
Post by Rob Landley
Post by enh
(this was a useful exercise because it showed that <scsi/sg.h> was still
missing from the NDK, so that bug should finally be fixed for real this
time.)
Yay!
Rob
_______________________________________________
Toybox mailing list
http://lists.landley.net/listinfo.cgi/toybox-landley.net
--
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.
Rob Landley
2017-12-03 07:16:10 UTC
Reply
Permalink
Raw Message
Post by enh
since rob asked on some other thread earlier this week...
NDK r15beta2 should hopefully ship in time for I/O in a couple of weeks,
so i had a quick go at building toybox out of the box with the latest
bits...
By the way, I've been meaning to ask:

$ /opt/android/x86_64/bin/clang --static -s hello.c && ls -l a.out
-rwxrwxr-x 1 landley landley 485880 Dec 2 22:10 a.out

$ ~/mcm/bin/x86_64-linux-musl-cc hello.c -s --static && ls -l a.out
-rwxrwxr-x 1 landley landley 17584 Dec 2 22:16 a.out

$ cat hello.c
#include <stdio.h>

int main(int argc, char *argv[])
{
printf("hello world %d\n", 5);

return 0;
}

Did that ever become... less bad? Yes, I'm forcing printf to do
something so gcc can't "optimize" it to puts, so it's a fair test. But
this seems to mostly be a "strip didn't" issue? A "grep -ai bionic" on
the stripped bionic binary (manually re-stripped to make sure) produced
stuff like:

0123456789ABCDEF0123456789abcdefconversion specifier
unsupportedbionic/libc/bionic/libc_logging.cppFORTIFY_SOURCE: %s.
Calling abort().open(O_CREAT): called without specifying a
modeopenat(O_CREAT): called without specifying a modeNo [stack] line
found in /proc/self/maps!pthread_create sched_setscheduler call failed:
%spthread_create failed: couldn't allocate threadpthread_create failed:
couldn't allocate %zd-byte stack: %spthread_create failed: couldn't
mprotect PROT_NONE %zd-byte stack guard region: %spthread_create failed:
clone failed: %sMath argument out of domain of funcToo many symbolic
links encounteredValue too large for defined data typeCan not access a
needed shared libraryAccessing a corrupted shared library.lib section in
a.out corruptedAttempting to link in too many shared librariesCannot
exec a shared library directlyInterrupted system call should be
restartedSocket operation on non-socketProtocol wrong type for
socketOperation not supported on transport endpointAddress family not
supported by protocolCannot assign requested addressNetwork dropped
connection because of resetSoftware caused connection abortTransport
endpoint is already connectedTransport endpoint is not connectedCannot
send after transport endpoint shutdownToo many references: cannot
splice%s(3) is not implemented on Android
strchr: prevented read past end of
bufferbionic/libc/upstream-netbsd/lib/libc/string/strcoll.cvoid
endusershell()void setusershell()char* getusershell()void
endpwent()/dev/socket/property_service

(Although I'm pretty sure the strchr warning near the end there is
ubuntu 14.04's grep being buggy. Did I mention I break everything?)

Rob
enh
2017-12-04 20:59:06 UTC
Reply
Permalink
Raw Message
Post by Rob Landley
Post by enh
since rob asked on some other thread earlier this week...
NDK r15beta2 should hopefully ship in time for I/O in a couple of weeks,
so i had a quick go at building toybox out of the box with the latest
bits...
$ /opt/android/x86_64/bin/clang --static -s hello.c && ls -l a.out
-rwxrwxr-x 1 landley landley 485880 Dec 2 22:10 a.out
$ ~/mcm/bin/x86_64-linux-musl-cc hello.c -s --static && ls -l a.out
-rwxrwxr-x 1 landley landley 17584 Dec 2 22:16 a.out
$ cat hello.c
#include <stdio.h>
int main(int argc, char *argv[])
{
printf("hello world %d\n", 5);
return 0;
}
Did that ever become... less bad? Yes, I'm forcing printf to do
something so gcc can't "optimize" it to puts, so it's a fair test. But
this seems to mostly be a "strip didn't" issue? A "grep -ai bionic" on
the stripped bionic binary (manually re-stripped to make sure) produced
very short version: the libc.a in the NDK hasn't changed in years
(https://github.com/android-ndk/ndk/issues/272).

but a current arm/arm64 static "hello world" is still large. it's not
something we care about. other than the dynamic linker, init and adbd
Android doesn't really use static binaries. (and once we can ignore
devices where / and /system aren't the same partition, we'll switch
init and adbd over too.)
Post by Rob Landley
0123456789ABCDEF0123456789abcdefconversion specifier
unsupportedbionic/libc/bionic/libc_logging.cppFORTIFY_SOURCE: %s.
Calling abort().open(O_CREAT): called without specifying a
modeopenat(O_CREAT): called without specifying a modeNo [stack] line
couldn't allocate %zd-byte stack: %spthread_create failed: couldn't
clone failed: %sMath argument out of domain of funcToo many symbolic
links encounteredValue too large for defined data typeCan not access a
needed shared libraryAccessing a corrupted shared library.lib section in
a.out corruptedAttempting to link in too many shared librariesCannot
exec a shared library directlyInterrupted system call should be
restartedSocket operation on non-socketProtocol wrong type for
socketOperation not supported on transport endpointAddress family not
supported by protocolCannot assign requested addressNetwork dropped
connection because of resetSoftware caused connection abortTransport
endpoint is already connectedTransport endpoint is not connectedCannot
send after transport endpoint shutdownToo many references: cannot
splice%s(3) is not implemented on Android
strchr: prevented read past end of
bufferbionic/libc/upstream-netbsd/lib/libc/string/strcoll.cvoid
endusershell()void setusershell()char* getusershell()void
endpwent()/dev/socket/property_service
(Although I'm pretty sure the strchr warning near the end there is
ubuntu 14.04's grep being buggy. Did I mention I break everything?)
no, that's one of our FORTIFY warnings. and printf calls strchr, so
that's not particularly surprising. something in the libc startup code
probably calls strerror, bringing in the big chunk of strerror strings
in the middle. pthreads aren't an optional extra to us, so every
program sets up the main thread ready for when the next thread is
created (which is the performance case for us), and that kind of
startup stuff seems to cover the rest of those.

and looking at the symbols with nm, i see all of jemalloc plus things
that are either potentially called by printf (if not for that
particular format string) or as part of libc startup. it all looks
plausible to me. and your numbers above are half the size i see from
building the same test with glibc :-)
--
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.
Loading...