[Lldb-commits] [lldb] [lldb] Remove support and workarounds for Android 4 and older (PR #124047)

[Pavel Labath via lldb-commits]

labath wrote:

All of these workarounds are very old. They date back to the time that API level 21 was brand sparkling new, we were trying to support everything back to level 8, and NDK headers were missing many important functions. This is why you can find references to highly questionable practices like linking to an level 21 libc but running on a leve 8 device. Android support hasn't gotten much attention since those days (though it seems it still works, yay), so nobody went through the trouble of figuring out which one of them is still needed.

> that's especially weird because execve() doesn't use $PATH ... it's the members of the exec family that have a 'p' in the name that do.

It's been a long time, but I'm pretty sure this was due to a test which ran something with an empty environment (some of our tests do that, sometimes deliberately, mostly by accident). It probably wasn't the binary itself that failed to launch, but that it then couldn't find the executable that *it* was trying to launch. The comment could be incorrect. Maybe it's (ba)sh who inserts `PATH=/bin:/usr/bin` into the environment if the variable is missing?

Bottom line: I'm pretty sure that the only reason this needs to be there is to make the test suite happy (and maybe not even that, if things have changed since that time). I don't think anyone is running the lldb test suite on android. If you're not planning to start doing that, I think we could delete it.

> i don't know what lldb's deprecation policy is (or Android Studio's, as "deliverers of the lldb"), but the ndk at least still supports api >= 21

I was asking this because I thought `android-4` is newer than `api-21`. It looks like that's not the case (though I'm pretty sure we did not call it "android 4" back in those days), so I think it's fine to keep it. It's pretty well encapsulated, and I don't think it has gotten in the way of anything.

> is there a workaround in android n? 

As I recall, we were cherry-picking the fix into all supported kernel branches (and maybe even adding conformance tests -- I'm not sure), so that at least new devices (starting from a new kernel branch should have it). But yes, it's possible that claim is too optimistic...

https://github.com/llvm/llvm-project/pull/124047