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

[via lldb-commits]

enh-google wrote:

> > 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?

it is, but mksh (Android's shell) does that too.

> 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.

even if anyone is, it might be better to delete this hack and then someone should come and hassle me if/when there's a test failure so we can try to work out what (if anything) is Android-specific here. if nothing else, we'll have a better code comment to add next time round :-)

@emrekultursay fyi, because i thought he _did_ run the lldb tests? but maybe i'm confused about which tests exactly...

> > 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.

heh, i've worked on Android since 2009 and i still struggle. https://apilevels.com/ is a godsend for this kind of thing, being a rosetta stone to translate between "whatever you have" and "whatever you need". (though personally i've given up on codenames and marketing names and only use api levels any more, and have even been retroactively changing documentation too. especially because [marketing name] "Android 16" is getting awfully close to something that sounds like an api level!)

> > 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...

ah, yes, it's coming back to me now --- it was you who wrote most of the excellent tests in https://cs.android.com/android/platform/superproject/main/+/main:bionic/tests/sys_ptrace_test.cpp wasn't it? i _think_ that the relevant tests weren't in CTS before api 28 though? certainly the copyright date for that whole file was 2016, so it can't have been much earlier than that, and certainly wasn't api 21.

(fyi, these tests found a linux kernel virtualization bug just recently: https://lore.kernel.org/lkml/Z5FVfe9RwVNr2PGI@google.com/ --- so thank you again for those!)

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