https://bugs.kde.org/show_bug.cgi?id=379878
Bug ID: 379878
Summary: most #if ... _linux_android checks wrong
Product: valgrind
Version: 3.13 SVN
Platform: Android
OS: Android 7.x
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: general
Assignee: jsew...@acm.org
Reporter: e...@google.com
Target Milestone: ---
forking from https://bugs.kde.org/show_bug.cgi?id=368529 rather than derail
that bug.
basically, everywhere there's currently #if...defined..._linux_android is
wrong. they're either missing a case (typically amd64), or they're covering too
much (it looks like whoever added arm64 just copy & pasted arm without thinking
about whether the same condition is true for arm64), or they're actually
Android-version-specific (i.e. the test shouldn't really "android on arm" but
"android before api level 9").
there distinguish between places that should say __BIONIC__, places that should
say __ANDROID__, places that should say __ANDROID_API__ <= 9, and places that
genuinely have a use for breaking out the individual architectures.
there's no way to express __ANDROID_API__ <= 9 within the existing system,
unless you want to go further and have VGPV_arm_linux_android_9 and
VGPV_arm_linux_android_10 and VGPV_arm_linux_android_11 and so on (for each of
the architectures), which doesn't seem like a good choice.
examples:
* the ashmem ioctl support should be __ANDROID__. it's Android-specific and
available on all architectures. (currently it's missing on amd64.) likewise
things like the "/system/bin/sh" versus "/bin/sh" should be __ANDROID__.
* the glibc __freeres support should be !defined(__BIONIC__) (or just __GLIBC__
since i'm not aware of any other libc that has a __freeres?)
* the AT_FPUCW checks should just be removed when NDK r15 ships.
* the "ignore zero-sized" check should explicitly check for gingerbread (which
is what the comment says) with __ANDROID_API__ <= 9. likewise the Elf32_Nhdr
redefinition should only happen if __ANDROID_API__ < 8 (froyo).
note that these are only examples: there are about 30 such places in the code.
what i'd like is just an agreement that this (using the appropriate check) is
how these should be fixed, and then i can prepare a patch. (which can obsolete
several of the outstanding android valgrind bugs, which are just fixing the
cases that cause build breaks.)
--
You are receiving this mail because:
You are watching all bug changes.
