| Age | Commit message (Collapse) | Author |
|---|
|
|
|
More of the files encountered on the Android system image (plus PE
executables, which we build but which shouldn't actually make it to the
system image!).
|
|
The Nexus Player build was subtly broken in that it assumed that the host was
using ELF. No-one noticed until a Mac user tried to flash their build, which
contained a Mach-O x86 binary instead of an ELF x86 binary. Hilarity ensued.
(On the same day, file(1) was able to explain a mixup with an ELF hexagon
binary. Next time we see a Mach-O binary on an Android device, we'll be ready!)
Bug: http://b/66741960
|
|
|
|
Everyone forgets that mmap returns MAP_FAILED rather than NULL on failure.
Every use of mmap in toybox was either doing the wrong check, or no check
at all (including the two I personally added).
|
|
|
|
isn't obviously useful.)
|
|
If we can read and write bzip2 files, we should be able to identify them
too...
|
|
An ELF file with no program headers is valid, and binutils leaves e_phentsize
zero in that case. Fix the corruption check to cope.
Also, since notes are in both the program and section headers (and I'm not
aware of the possibility of having no sections but still having notes ---
where would they be?), look for them in the section headers instead.
Also extend the parsing of the .android.note.ident ELF note to include the
NDK version information if present. (This won't be present for platform
binaries, but will be present for NDK-built binaries such as app libraries.)
|
|
|
|
On a toybox system, most of your bin directory is symbolic links.
Bug: http://b/31294746
|
|
then reading from stdin if it detected a file). Fixed it so "-" always
means stdin and you have to say ./- to look at a local "-".
Did some whitespace tweaks while I was there...
|
|
They're really just arbitrary byte sequences of arbitrary length.
Sure, a 20-byte sequence is _probably_ a SHA-1, but there's no way
to know, so let's stop pretending...
|
|
|
