Discussion:
[Toybox] Fun with the android NDK.
Rob Landley
2018-08-31 21:05:03 UTC
Permalink
So here's what I had to do to build and run toybox with the Android NDK:

1) I don't remember which NDK version I have installed and ls -l
/opt/android/x86-64 is unenlightening (NOTICE is 2400 lines of concatenated help
text starting with GPLv2, everything starting with "COPYING" is some variant of
GPL (yet MORE license text), repo.prop is a bunch of git hashes,
manifest_4639204.xml is not close enough to human readable to matter) but the
start of llvm-cc --version is "Android (4639204 based on r316199) clang version
6.0.1" which presumably means something to somebody. It's recent-ish. January maybe?

2) I applied the attached patch, some bits of which should get merged and others
I dunno about. (The structure ping wanted... did that git fixed upstream already?)

3) "LDFLAGS=--static CROSS_COMPILE=/opt/android/x86-64/bin/llvm- defconfig" and
then switch OFF CONFIG_LOG and CONFIG_GETCONF. The first I vaguely remember
talking about on here and the android guys intentionally don't export the log
functions in the NDK (but you can call the command line utility...?), the second
is missing posix stuff. (Is that fixed upstream or should I try to hack around
it here, or...?)

4) Build, with the same LDFLAGS and CROSS_COMPILE and run the result under
qemu-x86_64 -cpu Nehalem.f (The default cpu qemu emulates has the same immediate
segfault in the start code my netbook does, but if you have it fake an i7 it works.)

But hey, I have some sort of test environment now. :)

Rob
Ryan Prichard
2018-09-01 00:10:45 UTC
Permalink
Post by Rob Landley
1) I don't remember which NDK version I have installed and ls -l
/opt/android/x86-64 is unenlightening (NOTICE is 2400 lines of
concatenated help
text starting with GPLv2, everything starting with "COPYING" is some variant of
GPL (yet MORE license text), repo.prop is a bunch of git hashes,
manifest_4639204.xml is not close enough to human readable to matter) but the
start of llvm-cc --version is "Android (4639204 based on r316199) clang version
6.0.1" which presumably means something to somebody. It's recent-ish. January maybe?
FWIW: the NDK version is available in these files:
- source.properties
- sysroot/usr/include/android/ndk-version.h

That compiler version matches the one in r17 beta 1 (and not r16b or r17
beta 2).

The 4639204 is a build ID from Google's build server, and r316199 is an
LLVM SVN revision. I'm less sure about the 6.0.1. I _think_ the 6 probably
matches the upcoming major LLVM version as of r316199. e.g. r18 beta 2 has
version "Android (4751641 based on r328903) clang version 7.0.2", but
upstream Clang hasn't released 7.0.0 yet.

2) I applied the attached patch, some bits of which should get merged and
Post by Rob Landley
others
I dunno about. (The structure ping wanted... did that git fixed upstream already?)
It looks like there's a struct icmphdr in the NDK's UAPI header
linux/icmp.h. That header isn't usable on my glibc system because it
conflicts with the glibc netinet/ip_icmp.h header, but maybe it's OK to use
with the NDK, though?

-Ryan
Rob Landley
2018-09-03 16:31:54 UTC
Permalink
 - source.properties
 - sysroot/usr/include/android/ndk-version.h
There's no source.properites under the install but there is an ndk-version.h
with 17.0.1 in it. Good to know, thanks.
2) I applied the attached patch, some bits of which should get merged and others
I dunno about. (The structure ping wanted... did that git fixed upstream already?)
It looks like there's a struct icmphdr in the NDK's UAPI header linux/icmp.h.
That header isn't usable on my glibc system because it conflicts with the glibc
netinet/ip_icmp.h header, but maybe it's OK to use with the NDK, though?
I hit that conflict too. The problem is being ok to use with the NDK _now_
doesn't mean it won't add its own later and then hit the same conflict. (That's
why I put the local copy of the structucture definition under a new name in my
patch; ugly but avoids the conflict.)

What I'd like to do is get to the point where defconfig builds under the NDK
(switching off the appropriate commands as necessary in the compile-time
probes), and then regression test both ways (new NDK release and new toybox
release) as part of my quarterly release prep.

Another thing I'd like to do is have new (static) toybox binaries I can download
and use on old android releases. I was doing that with musl-cross-make but
bionic/llvm would be better. (They're _still_ selling Android K tablets at the
grocery store, and my Nexus 5 got upgraded to M a year after I bought it but
hasn't even had a bugfix release since 2016.) I'm aware stuff like ps wouldn't
have the selinux annotations to work right and things like the logger bindings
aren't available in the NDK, but for things like sed...

Except support for 32 bit's being dropped at some point and I dunno the schedule
of that in the ndk... hmmm. Is there a newsletter on this sort of thing? An
android version of lwn.net maybe?

Rob
enh
2018-09-06 21:35:16 UTC
Permalink
Post by Rob Landley
Post by Ryan Prichard
- source.properties
- sysroot/usr/include/android/ndk-version.h
There's no source.properites under the install but there is an ndk-version.h
with 17.0.1 in it. Good to know, thanks.
Post by Ryan Prichard
2) I applied the attached patch, some bits of which should get merged and others
I dunno about. (The structure ping wanted... did that git fixed upstream
already?)
It looks like there's a struct icmphdr in the NDK's UAPI header linux/icmp.h.
That header isn't usable on my glibc system because it conflicts with the glibc
netinet/ip_icmp.h header, but maybe it's OK to use with the NDK, though?
I hit that conflict too. The problem is being ok to use with the NDK _now_
doesn't mean it won't add its own later and then hit the same conflict. (That's
why I put the local copy of the structucture definition under a new name in my
patch; ugly but avoids the conflict.)
no need to worry. when i added the struct, i added the corresponding
unit test that it's visible when you include <netinet/ip_icmp.h>, so
we can't regress the user-visible part even if the exact location of
the struct changes.

commit e5a5eec5e588957aba2582ef25795bb3b573669f
Author: Elliott Hughes <***@google.com>
Date: Wed Jun 27 12:29:06 2018 -0700

<netinet/ip_icmp.h>: ensure struct icmphdr is available.

Needed to build toybox ping.

Bug: N/A
Test: ran tests
Change-Id: Ifd0f0ccbb8351c6a0ece526b050778fd02e984bf
Post by Rob Landley
What I'd like to do is get to the point where defconfig builds under the NDK
(switching off the appropriate commands as necessary in the compile-time
probes), and then regression test both ways (new NDK release and new toybox
release) as part of my quarterly release prep.
Another thing I'd like to do is have new (static) toybox binaries I can download
and use on old android releases. I was doing that with musl-cross-make but
bionic/llvm would be better. (They're _still_ selling Android K tablets at the
grocery store, and my Nexus 5 got upgraded to M a year after I bought it but
hasn't even had a bugfix release since 2016.) I'm aware stuff like ps wouldn't
have the selinux annotations to work right and things like the logger bindings
aren't available in the NDK, but for things like sed...
Except support for 32 bit's being dropped at some point and I dunno the schedule
of that in the ndk... hmmm. Is there a newsletter on this sort of thing? An
android version of lwn.net maybe?
roadmap: https://android.googlesource.com/platform/ndk/+/master/docs/Roadmap.md

release notes (which tend to include forward-looking announcements):
https://developer.android.com/ndk/downloads/revision_history

but, no, 32-bit isn't going anywhere any time soon. we *are* insisting
that folks have a 64-bit version of any 32-bit app so that at some
point it'll be possible to have a 64-bit-only device, but i assume
even that will only be another step in the slow decline of 32-bit.
(and remember that the NDK effectively has to worry about ~5-year old
devices, so even if you weren't allowed to ship a 32-bit P device
[which isn't true --- you totally can] it would still be ~2023 before
we could consider dropping 32-bit from the NDK [assuming that device
lifespan stays roughly where it currently is].)
Post by Rob Landley
Rob
_______________________________________________
Toybox mailing list
http://lists.landley.net/listinfo.cgi/toybox-landley.net
Rob Landley
2018-09-08 19:56:48 UTC
Permalink
Post by enh
Post by Rob Landley
I hit that conflict too. The problem is being ok to use with the NDK _now_
doesn't mean it won't add its own later and then hit the same conflict. (That's
why I put the local copy of the structucture definition under a new name in my
patch; ugly but avoids the conflict.)
no need to worry. when i added the struct, i added the corresponding
unit test that it's visible when you include <netinet/ip_icmp.h>, so
we can't regress the user-visible part even if the exact location of
the struct changes.
Ping seems to work as-is in the new NDK version, so yay.
Post by enh
Post by Rob Landley
Except support for 32 bit's being dropped at some point and I dunno the schedule
of that in the ndk... hmmm. Is there a newsletter on this sort of thing? An
android version of lwn.net maybe?
roadmap: https://android.googlesource.com/platform/ndk/+/master/docs/Roadmap.md
https://developer.android.com/ndk/downloads/revision_history
Oh good. I should link those from the toybox web page somewhere... Ah, under
android roadmap makes sense.

I see the plan to move to compiler-rt: Are you familiar with Rich Pennington's
http://ellcc.org ? He got a toolchain with no gnu components working a few years
ago, including compiler-rt. (He works down the hall from me at my current
contract, we keep meaning to sit down some evening and work out an update of
ellcc that would let me use his toolchain in my
https://github.com/landley/mkroot project but we've both been too busy so far...)
Post by enh
but, no, 32-bit isn't going anywhere any time soon. we *are* insisting
that folks have a 64-bit version of any 32-bit app so that at some
point it'll be possible to have a 64-bit-only device, but i assume
even that will only be another step in the slow decline of 32-bit.
32 bit's alive and well in the embedded space, and x32 remains interesting on 64
bit systems, but there's only 20 years until y2038...

(Embedded's weird: I'm told there are more nommu processors than with-mmu
processors in the world, which is about like saying there are more bacterial
cells than non-bacterial cells in the world. Embedded Linux is about like the
"insects" layer of the ecosystem, which is still flipping enormous.)
Post by enh
(and remember that the NDK effectively has to worry about ~5-year old
devices, so even if you weren't allowed to ship a 32-bit P device
I'm all for it. Toybox's historical horizon for working with old toolchains and
kernels and such is 7 years. :)
Post by enh
[which isn't true --- you totally can] it would still be ~2023 before
we could consider dropping 32-bit from the NDK [assuming that device
lifespan stays roughly where it currently is].)
Good to know. My personal experience has been... different.

Wikipedia[citation needed] says the Nexus 5 was introduced October 31, 2013, my
blog says I got mine for christmas 2014, and it got its last update October
2016. I.E. my phone was "supported" for just under 2 years after I bought it,
it's been a zombie for a couple years already, and 5 years from the hardware's
launch date isn't 'till halloween.

*shrug* I'm still using it (three screen replacements and a new battery later).
It's remotely exploitable at least 3 different ways I know of
(https://www.krackattacks.com/
https://www.theverge.com/2017/9/12/16294904/bluetooth-hack-exploit-android-linux-blueborne
), still running Marshmallow, and half the time I
want to use the camera I have to reboot the phone first. But there's no
guarantee T-mobile would support anything I move _to_ any longer than it did
this one, is there?

Still, it's nice Google's better about this than the phone companies. (I keep
meaning to put Oreo on it. I unlocked the bootloader last year when I disabled
the "Google App" in the because online insructions said that stopped flaky
earbud connections from popping up Google Voice every 30 seconds, and the
resulting boot loop required a factory reset to undo, and as long as the thing
was wiped _anyway_... only took 3 days. But I haven't tried to put an
experimental build on it because I use it as a phone; my netbook runs a stock
ubuntu LTS for the same reason. And every other device I've gotten to experiment
with, I _haven't_ managed to get the bootloader unlocked yet. Mostly due to lack
of deadline pressure I expect...)

Rob
enh
2018-09-08 20:21:06 UTC
Permalink
Post by Rob Landley
Post by enh
Post by Rob Landley
I hit that conflict too. The problem is being ok to use with the NDK _now_
doesn't mean it won't add its own later and then hit the same conflict. (That's
why I put the local copy of the structucture definition under a new name in my
patch; ugly but avoids the conflict.)
no need to worry. when i added the struct, i added the corresponding
unit test that it's visible when you include <netinet/ip_icmp.h>, so
we can't regress the user-visible part even if the exact location of
the struct changes.
Ping seems to work as-is in the new NDK version, so yay.
Post by enh
Post by Rob Landley
Except support for 32 bit's being dropped at some point and I dunno the schedule
of that in the ndk... hmmm. Is there a newsletter on this sort of thing? An
android version of lwn.net maybe?
roadmap: https://android.googlesource.com/platform/ndk/+/master/docs/Roadmap.md
https://developer.android.com/ndk/downloads/revision_history
Oh good. I should link those from the toybox web page somewhere... Ah, under
android roadmap makes sense.
I see the plan to move to compiler-rt: Are you familiar with Rich Pennington's
http://ellcc.org ? He got a toolchain with no gnu components working a few years
ago, including compiler-rt. (He works down the hall from me at my current
contract, we keep meaning to sit down some evening and work out an update of
ellcc that would let me use his toolchain in my
https://github.com/landley/mkroot project but we've both been too busy so far...)
oh, it basically works, but there are lots of missing pieces and
corner cases (that differ between architectures). the NDK tends to hit
more of these than the platform, because we have enough control over
the platform code to just work around problems when we need to.
Post by Rob Landley
Post by enh
but, no, 32-bit isn't going anywhere any time soon. we *are* insisting
that folks have a 64-bit version of any 32-bit app so that at some
point it'll be possible to have a 64-bit-only device, but i assume
even that will only be another step in the slow decline of 32-bit.
32 bit's alive and well in the embedded space, and x32 remains interesting on 64
bit systems, but there's only 20 years until y2038...
sadly i'm not sure that will be sufficient in general:
http://man7.org/linux/man-pages/man2/statx.2.html

this (or fixing time_t) would be ABI breaks for Android, though, so i
assume that 32-bit Android will go away, even if 32-bit Linux lives
on.
Post by Rob Landley
(Embedded's weird: I'm told there are more nommu processors than with-mmu
processors in the world, which is about like saying there are more bacterial
cells than non-bacterial cells in the world. Embedded Linux is about like the
"insects" layer of the ecosystem, which is still flipping enormous.)
Post by enh
(and remember that the NDK effectively has to worry about ~5-year old
devices, so even if you weren't allowed to ship a 32-bit P device
I'm all for it. Toybox's historical horizon for working with old toolchains and
kernels and such is 7 years. :)
Post by enh
[which isn't true --- you totally can] it would still be ~2023 before
we could consider dropping 32-bit from the NDK [assuming that device
lifespan stays roughly where it currently is].)
Good to know. My personal experience has been... different.
Wikipedia[citation needed] says the Nexus 5 was introduced October 31, 2013, my
blog says I got mine for christmas 2014, and it got its last update October
2016. I.E. my phone was "supported" for just under 2 years after I bought it,
it's been a zombie for a couple years already, and 5 years from the hardware's
launch date isn't 'till halloween.
my point is that even if your Nexus 5 hasn't had an OS update in a
couple of years, it can still download new apps. NDK r17 still
supports targeting >= ICS from 2011, which is several years older than
the oldest OS release that runs on Nexus 5.

when i say "device lifespan" i mean "years before users stop
installing apps on it, and app developers stop caring about it", not
"years it gets OS updates".

(fwiw, Nexus 5 got KitKat, Lollipop, and Marshmallow.)

the Android P version of the CDD
(https://source.android.com/compatibility/android-cdd) still allows
shipping new 32-bit devices. so the countdown timer to the NDK
dropping 32-bit support hasn't even started yet.
Post by Rob Landley
*shrug* I'm still using it (three screen replacements and a new battery later).
It's remotely exploitable at least 3 different ways I know of
(https://www.krackattacks.com/
https://www.theverge.com/2017/9/12/16294904/bluetooth-hack-exploit-android-linux-blueborne
http://youtu.be/TDk2RId8LFo ), still running Marshmallow, and half the time I
want to use the camera I have to reboot the phone first. But there's no
guarantee T-mobile would support anything I move _to_ any longer than it did
this one, is there?
Still, it's nice Google's better about this than the phone companies. (I keep
meaning to put Oreo on it. I unlocked the bootloader last year when I disabled
the "Google App" in the because online insructions said that stopped flaky
earbud connections from popping up Google Voice every 30 seconds, and the
resulting boot loop required a factory reset to undo, and as long as the thing
was wiped _anyway_... only took 3 days. But I haven't tried to put an
experimental build on it because I use it as a phone; my netbook runs a stock
ubuntu LTS for the same reason. And every other device I've gotten to experiment
with, I _haven't_ managed to get the bootloader unlocked yet. Mostly due to lack
of deadline pressure I expect...)
Rob
Rob Landley
2018-09-08 23:43:17 UTC
Permalink
On 09/08/2018 03:21 PM, enh wrote:>> I see the plan to move to compiler-rt: Are
you familiar with Rich Pennington's
Post by enh
Post by Rob Landley
http://ellcc.org ? He got a toolchain with no gnu components working a few years
ago, including compiler-rt. (He works down the hall from me at my current
contract, we keep meaning to sit down some evening and work out an update of
ellcc that would let me use his toolchain in my
https://github.com/landley/mkroot project but we've both been too busy so far...)
oh, it basically works, but there are lots of missing pieces and
corner cases (that differ between architectures). the NDK tends to hit
more of these than the platform, because we have enough control over
the platform code to just work around problems when we need to.
Let me know when there's a test build of a complete non-gpl toolchain. :)
Post by enh
Post by Rob Landley
Post by enh
but, no, 32-bit isn't going anywhere any time soon. we *are* insisting
that folks have a 64-bit version of any 32-bit app so that at some
point it'll be possible to have a 64-bit-only device, but i assume
even that will only be another step in the slow decline of 32-bit.
32 bit's alive and well in the embedded space, and x32 remains interesting on 64
bit systems, but there's only 20 years until y2038...
http://man7.org/linux/man-pages/man2/statx.2.html
Which is why x32 is a new API. Android probably wants to grow an x32 variant at
some point.
Post by enh
this (or fixing time_t) would be ABI breaks for Android, though, so i
assume that 32-bit Android will go away, even if 32-bit Linux lives
on.
20 years is a long time, and "here's a new API, old one is deprecated" is
probably going to be required for Android at some point between now and then.
Even Microsoft gave up on full backwards compatibility after about 20 years:

https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost-the-api-war/

That said 20 years is not _that_ long (1998 to now), and the end of moore's law
makes it more predictable. I expect all the _processors_ to be 64 bit by then,
but an x32 mode is probably still likely to be useful if memory bus bandwidth
and how much stack space fits in L1 cache remain constraining in any way.

The s-curve of Moore's Law started bending back down in 2000 (when Intel
recalled its overclocked 1.13ghz pentium III http://www.anandtech.com/show/613
and processor development went wide instead of clocking faster). A couple years
later Gordon Moore gave a speech called "No Exponential Is Forever" basically
warning the industry that the curve was bending down.
https://ethw.org/Archives:No_Exponential_is_Forever then in 2004 Intel cancelled
its 4ghz chip http://www.pcworld.com/article/118603/article.html and went wide
instead, then core duo (intel's first on-die SMP) shipped in January 2006. Going
wide bought another decade, but Moore's speech was something like 16 years ago
now and spectre and meltdown feel kinda end-gamey for single-threaded
performance improvements. But the head of the ACM called the end of Moore's Law
even before that: https://www.acm.org/articles/people-of-acm/2016/david-patterson

The big driver for both memory and storage consumption since the DOS days has
been increasing display resolution and video, but a 4k display is the same
resolution as digital cinema blown up on the wall of a theatre
https://en.wikipedia.org/wiki/Digital_cinema and the point of a "retina display"
is it's at the limits of human perception, and frame rate increases have been
kinda meh too (movies have been at at 24 frames and TV at 30-ish for most of a
century,
), we've _already_ doubled
that today, so that's near endgame too...

I'm sure we'll come up with new stuff over the next 20 years but ideas like
"solar powered phone" and "longer battery life" almost call for _less_
performance. (Yes, I say that wanting to turn android phones into self-hosting
development systems, and building the whole of AOSP on a current high-end phone
is probably something like 24 hours. I'm not saying this is what I _want_, it's
what I _expect_.)

That's why 4 gigabytes being sufficiently more than most individual applications
currently use today seems like it should still being a generally useful compile
time option in 20 years. (The _system_ will probably want (at least) 64 gigs,
there's an app/OS split and then the GPU has its own address space so your
textures don't have to stay mapped...)

*shrug* We'll see. But I expect a 32 bit API to survive y2038.
Post by enh
my point is that even if your Nexus 5 hasn't had an OS update in a
couple of years, it can still download new apps. NDK r17 still
supports targeting >= ICS from 2011, which is several years older than
the oldest OS release that runs on Nexus 5.
when i say "device lifespan" i mean "years before users stop
installing apps on it, and app developers stop caring about it", not
"years it gets OS updates".
Ah, that's why the default is the _oldest_ API level. Makes sense now.
Post by enh
(fwiw, Nexus 5 got KitKat, Lollipop, and Marshmallow.)
People have built Oreo for it. But while I'm in milwaukee most of my internet
access goes through it, so reimaging it would be problematic.
Post by enh
the Android P version of the CDD
(https://source.android.com/compatibility/android-cdd) still allows
shipping new 32-bit devices. so the countdown timer to the NDK
dropping 32-bit support hasn't even started yet.
There's an Oreo build for the Nexus 5. I should try to image the sucker, I just
want to do so first on a device I _won't_ be significantly inconvenienced by
bricking. (I break everything.)

Rob
David Seikel
2018-09-09 03:46:36 UTC
Permalink
Post by Rob Landley
The big driver for both memory and storage consumption since the DOS
days has been increasing display resolution and video, but a 4k
display is the same resolution as digital cinema blown up on the wall
of a theatre https://en.wikipedia.org/wiki/Digital_cinema and the
point of a "retina display" is it's at the limits of human
perception, and frame rate increases have been kinda meh too (movies
have been at at 24 frames and TV at 30-ish for most of a century,
http://youtu.be/EM16aiSSpFk ), we've _already_
doubled that today, so that's near endgame too...
I'm sure we'll come up with new stuff over the next 20 years but
My Motorola Moto Z phone is basically a "retina display", even taking my
glasses off and squinting at it with my horribly short sighted vision,
I can't see pixels. Strapping it to my head in a Google Daydream is a
whole other story though, rather low res, not enough resolution to be a
monitor replacement. Oculus and friends insist on 90 Hz frame rates, to
stop people feeling ill, but lower rates work fine for "never gets ill"
me, YMMV. 4k per eye at 90 Hz frame rate for augmented / virtual
reality headsets is likely coming soonish. Then again, tricks like
foveated rendering will reduce the amount of high res pixels needed
(tracking what part of the display your eyeball is actually focused on,
and only rendering that bit in high res). That's driving things a bit
for now.
--
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
Rob Landley
2018-09-10 19:31:46 UTC
Permalink
Post by David Seikel
Post by Rob Landley
I'm sure we'll come up with new stuff over the next 20 years but
My Motorola Moto Z phone is basically a "retina display", even taking my
glasses off and squinting at it with my horribly short sighted vision,
I can't see pixels. Strapping it to my head in a Google Daydream is a
whole other story though, rather low res, not enough resolution to be a
monitor replacement. Oculus and friends insist on 90 Hz frame rates, to
stop people feeling ill, but lower rates work fine for "never gets ill"
me, YMMV. 4k per eye at 90 Hz frame rate for augmented / virtual
reality headsets is likely coming soonish. Then again, tricks like
foveated rendering will reduce the amount of high res pixels needed
(tracking what part of the display your eyeball is actually focused on,
and only rendering that bit in high res). That's driving things a bit
for now.
Development's not going to stop. (Heck, they're still managing die size shrinks,
and seem bound and determined to throw money at the problem all the way to
atomic limits: https://en.wikipedia.org/wiki/5_nanometer#Beyond_5_nm . And
there's still plenty of drivers: I mentioned wanting a phone with 64 gigs of
ram. The 128TB of storage the newest SD spec (SDUC) can handle would be nice
too, but we'll see...)

I'm just trying to figure out whether x32 (and whatever the arm equivalent is)
will remain relevant after the y2038 issue takes out legacy unmigrated 32 bit
systems. I suspect it will, and if it survives that it could easily last a
century, 20 years from now the moore's law s-curve's should have flattened the
rest of the way out to a linear rate of advance.

I have some history doing this sort of analysis, but "predictions are hard,
especially about the future". People have a periodic tendency to go "this is
good enough, let's go for cheaper/smaller/lower power instead of more
performance", and as things increase other things become bottlenecks...

http://landley.net/notes-2011.html#26-06-2011

Rob

P.S. I googled, the arm equivalent is https://wiki.debian.org/Arm64ilp32Port
which is an even sillier name than aaarch64. But presumably has a 64 bit time_t.

P.P.S. Things like x32 become _more_ interesting as the moore's law s-curve
flattens out. It's the kind of advance you care about in a world of linear
performance increases. Thus it seems worth trying to preserve 32 bit support and
fix its issues in toybox...
enh
2018-09-01 19:00:18 UTC
Permalink
Post by Rob Landley
1) I don't remember which NDK version I have installed and ls -l
/opt/android/x86-64 is unenlightening (NOTICE is 2400 lines of concatenated help
text starting with GPLv2, everything starting with "COPYING" is some variant of
GPL (yet MORE license text), repo.prop is a bunch of git hashes,
manifest_4639204.xml is not close enough to human readable to matter) but the
start of llvm-cc --version is "Android (4639204 based on r316199) clang version
6.0.1" which presumably means something to somebody. It's recent-ish. January maybe?
if you're missing a CHANGELOG.md file, you should definitely upgrade.
otherwise that will tell you what version you're using.

sysroot/usr/include/android/ndk-version.h also has the details, for
programmatic use.
Post by Rob Landley
2) I applied the attached patch, some bits of which should get merged and others
I dunno about. (The structure ping wanted... did that git fixed upstream already?)
yeah, icmphdr is there for me.

as for the initializations, i'm always happy to see such changes, but
i haven't needed them personally. i suspect you're using GCC rather
than clang? (GCC will be removed in r18, some time this month.) here
are the `-Wno-`s i need to be able to build with the Android-preferred
-Wall -Werror:

"-Wno-char-subscripts",
"-Wno-gnu-variable-sized-type-not-at-end",
"-Wno-missing-field-initializers",
"-Wno-sign-compare",
"-Wno-string-plus-int",
"-Wno-unused-parameter",
Post by Rob Landley
3) "LDFLAGS=--static CROSS_COMPILE=/opt/android/x86-64/bin/llvm- defconfig" and
then switch OFF CONFIG_LOG and CONFIG_GETCONF. The first I vaguely remember
talking about on here and the android guys intentionally don't export the log
functions in the NDK (but you can call the command line utility...?), the second
is missing posix stuff. (Is that fixed upstream or should I try to hack around
it here, or...?)
yeah, for the platform i have

# CONFIG_GETCONF is not set
CONFIG_LOG=y

getconf seems to be without any real value.

__android_log_write is in the NDK.
Post by Rob Landley
4) Build, with the same LDFLAGS and CROSS_COMPILE and run the result under
qemu-x86_64 -cpu Nehalem.f (The default cpu qemu emulates has the same immediate
segfault in the start code my netbook does, but if you have it fake an i7 it works.)
But hey, I have some sort of test environment now. :)
Rob
_______________________________________________
Toybox mailing list
http://lists.landley.net/listinfo.cgi/toybox-landley.net
Rob Landley
2018-09-03 16:54:38 UTC
Permalink
Post by enh
Post by Rob Landley
1) I don't remember which NDK version I have installed and ls -l
/opt/android/x86-64 is unenlightening (NOTICE is 2400 lines of concatenated help
text starting with GPLv2, everything starting with "COPYING" is some variant of
GPL (yet MORE license text), repo.prop is a bunch of git hashes,
manifest_4639204.xml is not close enough to human readable to matter) but the
start of llvm-cc --version is "Android (4639204 based on r316199) clang version
6.0.1" which presumably means something to somebody. It's recent-ish. January maybe?
if you're missing a CHANGELOG.md file, you should definitely upgrade.
otherwise that will tell you what version you're using.
I deleted the download directory and only have the "relocated" directory it
installed into /opt. I just have the standalone install.
Post by enh
sysroot/usr/include/android/ndk-version.h also has the details, for
programmatic use.
Yup. 17.0-beta1
Post by enh
Post by Rob Landley
2) I applied the attached patch, some bits of which should get merged and others
I dunno about. (The structure ping wanted... did that git fixed upstream already?)
yeah, icmphdr is there for me.
Cool. Any idea when it shows up in the ndk? Let's see, download 18-beta2...

Ooh! Ha, I hadn't noticed:

https://developer.android.com/ndk/guides/standalone_toolchain

You use toybox as a build example. Very nice. I'll give these instructions a try
and add them to my testing thing...

Hmmm. In theory toybox expects you to set CROSS_COMPILE (same as thelinux
kernel). If you set CC that'll work fo the build, but not for "make defconfig",
it'll try to use your target compiler to build the kconfig plumbing from 2.6.12?
I _really_ need to rewrite that stuff, it's the only gpl build plumbing left in
the project, and the kernel guys rewrote it to be turing complete recently which
is not a direction I want to go in...)

# ~/android-ndk-r18-beta2$ build/tools/make_standalone_toolchain.py --arch=arm64
--api 26 --stl=libc++ --install-dir=~/ndk

It created a ~ subdirectory under the extracted android ndk directory. Of course
it did.
Post by enh
as for the initializations, i'm always happy to see such changes, but
i haven't needed them personally. i suspect you're using GCC rather
than clang?
I used the llvm- prefix.
Post by enh
(GCC will be removed in r18, some time this month.) here
are the `-Wno-`s i need to be able to build with the Android-preferred
"-Wno-char-subscripts",
"-Wno-gnu-variable-sized-type-not-at-end",
That one's my bad, I need to fix it. (The linestack stuff is unfinished, I
really need to get back to it and actually implement a text editor and such.)
Post by enh
"-Wno-missing-field-initializers",
"-Wno-sign-compare",
"-Wno-string-plus-int",
"-Wno-unused-parameter",
Hmmm...
Post by enh
Post by Rob Landley
3) "LDFLAGS=--static CROSS_COMPILE=/opt/android/x86-64/bin/llvm- defconfig" and
then switch OFF CONFIG_LOG and CONFIG_GETCONF. The first I vaguely remember
talking about on here and the android guys intentionally don't export the log
functions in the NDK (but you can call the command line utility...?), the second
is missing posix stuff. (Is that fixed upstream or should I try to hack around
it here, or...?)
yeah, for the platform i have
# CONFIG_GETCONF is not set
CONFIG_LOG=y
getconf seems to be without any real value.
The kernel build grew a dependency on it, although it's not a deep dependency
yet (it spits out a lot of "getconf not found" stuff but _mostly_ falls back to
sane defaults), and if I was going to add it, I might as well do it right...
Post by enh
__android_log_write is in the NDK.
I'll upgrade the version and try it again.

Thanks,

Rob
Rob Landley
2018-09-06 15:43:23 UTC
Permalink
Post by Rob Landley
Post by enh
__android_log_write is in the NDK.
I'll upgrade the version and try it again.
Ok, installed android-ndk-r18-beta2 with

build/tools/make_standalone_toolchain.py --arch=x86_64 --api 28 \
--stl=libc++ --install-dir=$(readlink -f ~/android/x86_64)

then

LDFLAGS=--static CROSS_COMPILE=~/android/x86_64/bin/llvm- \
make distclean defconfig

and

LDFLAGS=--static CROSS_COMPILE=~/android/x86_64/bin/llvm- make

Getconfig still died because

./generated/getconf.h:5:1: error: use of undeclared identifier '_CS_PATH'
_CS_PATH,_CS_V7_ENV
^
./generated/getconf.h:5:10: error: use of undeclared identifier '_CS_V7_ENV'
_CS_PATH,_CS_V7_ENV
^
toys/posix/getconf.c:139:9: error: implicit declaration of function 'confstr' is
invalid in C99 [-Werror,-Wimplicit-function-declaration]
confstr(confstr_vals[j], toybuf, sizeof(toybuf));

Ok, switch that off and rebuild (I should add a compile-time probe for confstr),
and...

generated/obj/log.o:log.c:function log_main: error: undefined reference to
'__android_log_write'

Your statement that this was in the NDK does not appear to be the case yet. Ok,
switch off CONFIG_LOG and:

lvm-strip: Unknown command line argument '-o'. Try:
'/home/landley/android/x86_64/bin/llvm-strip -help'
llvm-strip: Did you mean '-O'?

The prefixed llvm-strip doesn't know the "-o" option specifying output file.
Hmmm... well, it isn't in posix-2008, I suppose they have a point. I can cp and
then strip?

$ ls -l toybox
-r-xr-xr-x 1 landley landley 4213840 Sep 5 14:47 toybox
$ ~/android/x86_64/bin/llvm-strip toybox
$ ls -l toybox
-rwxrwxr-x 1 landley landley 4215248 Sep 5 14:50 toybox

Oh bravo, stripping it made it 2k _bigger_. How the...

$ strip toybox
$ ls -l toybox
-rwxrwxr-x 1 landley landley 930944 Sep 5 14:52 toybox

The host one knows how to strip it. And defconfig-ish build is still 930k. With
glibc it's:

$ ls -l toybox
-r-xr-xr-x 1 landley landley 1435128 Sep 5 14:59 toybox

And with musl-libc it's:

$ ls -l toybox
-r-xr-xr-x 1 landley landley 567240 Sep 5 15:02 toybox

So that's sane I suppose...

Rob
enh
2018-09-06 22:11:44 UTC
Permalink
Post by Rob Landley
Post by Rob Landley
Post by enh
__android_log_write is in the NDK.
I'll upgrade the version and try it again.
Ok, installed android-ndk-r18-beta2 with
build/tools/make_standalone_toolchain.py --arch=x86_64 --api 28 \
--stl=libc++ --install-dir=$(readlink -f ~/android/x86_64)
then
LDFLAGS=--static CROSS_COMPILE=~/android/x86_64/bin/llvm- \
make distclean defconfig
and
LDFLAGS=--static CROSS_COMPILE=~/android/x86_64/bin/llvm- make
Getconfig still died because
./generated/getconf.h:5:1: error: use of undeclared identifier '_CS_PATH'
_CS_PATH,_CS_V7_ENV
^
./generated/getconf.h:5:10: error: use of undeclared identifier '_CS_V7_ENV'
_CS_PATH,_CS_V7_ENV
^
toys/posix/getconf.c:139:9: error: implicit declaration of function 'confstr' is
invalid in C99 [-Werror,-Wimplicit-function-declaration]
confstr(confstr_vals[j], toybuf, sizeof(toybuf));
Ok, switch that off and rebuild (I should add a compile-time probe for confstr),
(makes sense. i don't see us adding confstr(3) to Android any time soon.)
Post by Rob Landley
and...
generated/obj/log.o:log.c:function log_main: error: undefined reference to
'__android_log_write'
Your statement that this was in the NDK does not appear to be the case yet.
at a guess, you're not linking liblog? the logging functions aren't in libc.
Post by Rob Landley
Ok,
'/home/landley/android/x86_64/bin/llvm-strip -help'
llvm-strip: Did you mean '-O'?
The prefixed llvm-strip doesn't know the "-o" option specifying output file.
we've had a lot of issues with llvm-strip, so you probably want to
stick to the binutils one for now.
Post by Rob Landley
Hmmm... well, it isn't in posix-2008, I suppose they have a point. I can cp and
then strip?
$ ls -l toybox
-r-xr-xr-x 1 landley landley 4213840 Sep 5 14:47 toybox
$ ~/android/x86_64/bin/llvm-strip toybox
$ ls -l toybox
-rwxrwxr-x 1 landley landley 4215248 Sep 5 14:50 toybox
Oh bravo, stripping it made it 2k _bigger_. How the...
$ strip toybox
$ ls -l toybox
-rwxrwxr-x 1 landley landley 930944 Sep 5 14:52 toybox
The host one knows how to strip it. And defconfig-ish build is still 930k. With
$ ls -l toybox
-r-xr-xr-x 1 landley landley 1435128 Sep 5 14:59 toybox
$ ls -l toybox
-r-xr-xr-x 1 landley landley 567240 Sep 5 15:02 toybox
So that's sane I suppose...
Rob
Rob Landley
2018-09-08 21:18:55 UTC
Permalink
Post by enh
Post by Rob Landley
Ok, switch that off and rebuild (I should add a compile-time probe for confstr),
(makes sense. i don't see us adding confstr(3) to Android any time soon.)
I added an #ifdef to portability.h to build getconf with the NDK.
Post by enh
Post by Rob Landley
and...
generated/obj/log.o:log.c:function log_main: error: undefined reference to
'__android_log_write'
Your statement that this was in the NDK does not appear to be the case yet.
at a guess, you're not linking liblog? the logging functions aren't in libc.
It's in the library probe list but the ndk only has liblog.so, not liblog.a, so
the probe goes "it's not there" when building statically. (And I can't run the
dynamic build on an ubuntu host.)

Other than that, I just checked in the fixes and defconfig builds. Can't run it
until I can link it, but just the one warning left, which is an issue I should
fix in the code but probably not this weekend.

Oh, I had to create an llvm-cc symlink to "clang". (CROSS_COMPILE needs prefixed
versions of all the names.)
Post by enh
Post by Rob Landley
Ok,
'/home/landley/android/x86_64/bin/llvm-strip -help'
llvm-strip: Did you mean '-O'?
The prefixed llvm-strip doesn't know the "-o" option specifying output file.
we've had a lot of issues with llvm-strip, so you probably want to
stick to the binutils one for now.
If I provide a prefix, the build uses the prefixed version for strip. Kinda
awkward not to: until now it's been consistent and I got in the habit of being
SURE to use all the prefixed commands for the target at each step and not leak
host toolchain stuff anywhere...

That said, strip basically being a NOP works for me, the result runs and is
testable and the toolchain can get fixed when it gets fixed.

Rob

P.S. The _reason_ you can't use the host strip when cross compiling, the first
one I hit anyway, is that back in the 90's the sh4 hardware developers used
versions of the elf spec translated into japanese to implement their compiler,
and the translation switched codepages in a way that turned _ into a period. So
their assembly prefix on sh4 in the Hitachi compiler was implemented as "."
following the translated docs, and that became the sh4 standard. But the x86
strip converted whatever prefix you were using into _ in some places (just
overwriting whatever was there), and the resulting x86 binary couldn't find
_start. I.E. using x86 strip on an sh4 executable broke it. Maybe they've fixed
it now?
enh
2018-09-06 22:46:41 UTC
Permalink
Post by Rob Landley
Post by enh
Post by Rob Landley
1) I don't remember which NDK version I have installed and ls -l
/opt/android/x86-64 is unenlightening (NOTICE is 2400 lines of concatenated help
text starting with GPLv2, everything starting with "COPYING" is some variant of
GPL (yet MORE license text), repo.prop is a bunch of git hashes,
manifest_4639204.xml is not close enough to human readable to matter) but the
start of llvm-cc --version is "Android (4639204 based on r316199) clang version
6.0.1" which presumably means something to somebody. It's recent-ish. January maybe?
if you're missing a CHANGELOG.md file, you should definitely upgrade.
otherwise that will tell you what version you're using.
I deleted the download directory and only have the "relocated" directory it
installed into /opt. I just have the standalone install.
Post by enh
sysroot/usr/include/android/ndk-version.h also has the details, for
programmatic use.
Yup. 17.0-beta1
Post by enh
Post by Rob Landley
2) I applied the attached patch, some bits of which should get merged and others
I dunno about. (The structure ping wanted... did that git fixed upstream already?)
yeah, icmphdr is there for me.
Cool. Any idea when it shows up in the ndk? Let's see, download 18-beta2...
https://developer.android.com/ndk/guides/standalone_toolchain
You use toybox as a build example. Very nice. I'll give these instructions a try
and add them to my testing thing...
Hmmm. In theory toybox expects you to set CROSS_COMPILE (same as thelinux
kernel). If you set CC that'll work fo the build, but not for "make defconfig",
it'll try to use your target compiler to build the kconfig plumbing from 2.6.12?
I _really_ need to rewrite that stuff, it's the only gpl build plumbing left in
the project, and the kernel guys rewrote it to be turing complete recently which
is not a direction I want to go in...)
# ~/android-ndk-r18-beta2$ build/tools/make_standalone_toolchain.py --arch=arm64
--api 26 --stl=libc++ --install-dir=~/ndk
It created a ~ subdirectory under the extracted android ndk directory. Of course
it did.
(i was going to file a bug at
https://github.com/android-ndk/ndk/issues/new but danalbert fixed it
quicker than i could file the bug [because i was looking up the
mailing list to give a link to this thread...]. turns out he naturally
uses "--install-dir ~/ndk" which obviously is the shell's problem
rather than python's...
https://android-review.googlesource.com/c/platform/ndk/+/749658 )
Post by Rob Landley
Post by enh
as for the initializations, i'm always happy to see such changes, but
i haven't needed them personally. i suspect you're using GCC rather
than clang?
I used the llvm- prefix.
"there be dragons"... we're moving the platform off binutils as i
speak, but it's very much a work in progress, and we're finding lots
of bugs/differences from binutils.
Post by Rob Landley
Post by enh
(GCC will be removed in r18, some time this month.) here
are the `-Wno-`s i need to be able to build with the Android-preferred
"-Wno-char-subscripts",
"-Wno-gnu-variable-sized-type-not-at-end",
That one's my bad, I need to fix it. (The linestack stuff is unfinished, I
really need to get back to it and actually implement a text editor and such.)
Post by enh
"-Wno-missing-field-initializers",
"-Wno-sign-compare",
"-Wno-string-plus-int",
"-Wno-unused-parameter",
Hmmm...
Post by enh
Post by Rob Landley
3) "LDFLAGS=--static CROSS_COMPILE=/opt/android/x86-64/bin/llvm- defconfig" and
then switch OFF CONFIG_LOG and CONFIG_GETCONF. The first I vaguely remember
talking about on here and the android guys intentionally don't export the log
functions in the NDK (but you can call the command line utility...?), the second
is missing posix stuff. (Is that fixed upstream or should I try to hack around
it here, or...?)
yeah, for the platform i have
# CONFIG_GETCONF is not set
CONFIG_LOG=y
getconf seems to be without any real value.
The kernel build grew a dependency on it, although it's not a deep dependency
yet (it spits out a lot of "getconf not found" stuff but _mostly_ falls back to
sane defaults), and if I was going to add it, I might as well do it right...
to be clear[er than i was], i actually meant confstr(3).
Post by Rob Landley
Post by enh
__android_log_write is in the NDK.
I'll upgrade the version and try it again.
Thanks,
Rob
Rob Landley
2018-09-08 22:09:15 UTC
Permalink
Post by enh
Post by Rob Landley
It created a ~ subdirectory under the extracted android ndk directory. Of course
it did.
(i was going to file a bug at
https://github.com/android-ndk/ndk/issues/new but danalbert fixed it
quicker than i could file the bug [because i was looking up the
mailing list to give a link to this thread...]. turns out he naturally
uses "--install-dir ~/ndk" which obviously is the shell's problem
rather than python's...
https://android-review.googlesource.com/c/platform/ndk/+/749658 )
I break everything.
Post by enh
Post by Rob Landley
Post by enh
as for the initializations, i'm always happy to see such changes, but
i haven't needed them personally. i suspect you're using GCC rather
than clang?
I used the llvm- prefix.
"there be dragons"... we're moving the platform off binutils as i
speak, but it's very much a work in progress, and we're finding lots
of bugs/differences from binutils.
It's sad the guy who did Gold (and wrote up a great series of blog posts about
all the issues he hit, starting at https://www.airs.com/blog/archives/38 )
signed the result over to the FSF to be buried in a GPLv3 sea trench.
Post by enh
Post by Rob Landley
Post by enh
(GCC will be removed in r18, some time this month.) here
are the `-Wno-`s i need to be able to build with the Android-preferred
"-Wno-char-subscripts",
Why is an array subscript of type char objectionable?

I already have that in my default $CFLAGS from last time:

[ -z "$CFLAGS" ] && CFLAGS="-Wall -Wundef -Wno-char-subscripts
-Werror=implicit-function-declaration"
Post by enh
Post by Rob Landley
Post by enh
"-Wno-gnu-variable-sized-type-not-at-end",
That one's my bad, I need to fix it. (The linestack stuff is unfinished, I
really need to get back to it and actually implement a text editor and such.)
Post by enh
"-Wno-missing-field-initializers",
"-Wno-sign-compare",
"-Wno-string-plus-int",
"-Wno-unused-parameter",
I didn't need to set any of those with the the new NDK? (Not to build defconfig
anyway, maybe it's in the pending stuff you're building...)
Post by enh
Post by Rob Landley
The kernel build grew a dependency on it, although it's not a deep dependency
yet (it spits out a lot of "getconf not found" stuff but _mostly_ falls back to
sane defaults), and if I was going to add it, I might as well do it right...
to be clear[er than i was], i actually meant confstr(3).
Added to portability.h (Hardwiring in the output of the 2 cases we were using.)

(I dunno why the v7 case is there, it was there in
https://landley.net/notes-2017.html#18-02-2017 but doesn't seem to be in the gnu
version? Huh. I didn't use their code, but did use their symbol list...)
Post by enh
Post by Rob Landley
Post by enh
__android_log_write is in the NDK.
I'll upgrade the version and try it again.
I Did The Thing and it just needs llvm-cc and liblog.a. (A working strip -o
would be nice but the existing build works around that.)

Rob
Rob Landley
2018-09-08 22:19:52 UTC
Permalink
Post by enh
Post by Rob Landley
Post by enh
as for the initializations, i'm always happy to see such changes, but
i haven't needed them personally. i suspect you're using GCC rather
than clang?
I used the llvm- prefix.
"there be dragons"... we're moving the platform off binutils as i
speak, but it's very much a work in progress, and we're finding lots
of bugs/differences from binutils.
The 4.18 kernel will not build with this toolchain, by the way.

$ make allnoconfig KCONFIG_ALLCONFIG=x86_64.miniconf
CROSS_COMPILE=~/android/x86_64/bin/llvm-
arch/x86/Makefile:184: *** Compiler lacks asm-goto support.. Stop.

Commit e501ce957a78 from january, part of the spectre/meltdown mitigation stuff.

Rob
enh
2018-10-05 23:50:37 UTC
Permalink
Post by Rob Landley
Post by enh
Post by Rob Landley
Post by enh
as for the initializations, i'm always happy to see such changes, but
i haven't needed them personally. i suspect you're using GCC rather
than clang?
I used the llvm- prefix.
"there be dragons"... we're moving the platform off binutils as i
speak, but it's very much a work in progress, and we're finding lots
of bugs/differences from binutils.
The 4.18 kernel will not build with this toolchain, by the way.
$ make allnoconfig KCONFIG_ALLCONFIG=x86_64.miniconf
CROSS_COMPILE=~/android/x86_64/bin/llvm-
arch/x86/Makefile:184: *** Compiler lacks asm-goto support.. Stop.
yeah, a sister team has someone working on that. (we build Pixel
kernels with clang already.)
Post by Rob Landley
Commit e501ce957a78 from january, part of the spectre/meltdown mitigation stuff.
Rob
Rob Landley
2018-10-06 17:27:36 UTC
Permalink
Post by enh
Post by Rob Landley
The 4.18 kernel will not build with this toolchain, by the way.
$ make allnoconfig KCONFIG_ALLCONFIG=x86_64.miniconf
CROSS_COMPILE=~/android/x86_64/bin/llvm-
arch/x86/Makefile:184: *** Compiler lacks asm-goto support.. Stop.
yeah, a sister team has someone working on that. (we build Pixel
kernels with clang already.)
Sigh. I kept gcc 4.2.1 and binutils 2.17 building multiple architectures for 10
years after they shipped, and maintained my own tinycc fork for 3 years trying
to extend that to build the kernel.

Sitting on my hands on this one, just a bit antsy. :)

(There isn't a public github archive I can build the NDK from, is there?)

Rob
enh
2018-10-06 23:07:20 UTC
Permalink
Post by Rob Landley
Post by enh
Post by Rob Landley
The 4.18 kernel will not build with this toolchain, by the way.
$ make allnoconfig KCONFIG_ALLCONFIG=x86_64.miniconf
CROSS_COMPILE=~/android/x86_64/bin/llvm-
arch/x86/Makefile:184: *** Compiler lacks asm-goto support.. Stop.
yeah, a sister team has someone working on that. (we build Pixel
kernels with clang already.)
Sigh. I kept gcc 4.2.1 and binutils 2.17 building multiple architectures for 10
years after they shipped, and maintained my own tinycc fork for 3 years trying
to extend that to build the kernel.
Sitting on my hands on this one, just a bit antsy. :)
(There isn't a public github archive I can build the NDK from, is there?)
https://android.googlesource.com/platform/ndk/+/master/README.md#Building-the-NDK

but i think what you really want here is a new clang with the asm-goto
stuff? that work's still happening in llvm upstream.

we no longer have forked compilers in the NDK: they're the exact same
platform ones.
Post by Rob Landley
Rob
Loading...