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
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to