xiaobai added a comment. In D68048#1683238 <https://reviews.llvm.org/D68048#1683238>, @clayborg wrote:
> > There are some things still left. > > > > architecture: > > I don't know if we can simply reuse an existing variable and set it for > > all processes, or if we should really find the architecture of each process. > > The only time we might run into an issue is when we have arm32 running on > arm64. Not sure if that can be detected. For now we can deduce the devices > architecture and apply to all? If you ask the device for what architectures it supports, you could get a list. It might be worth figuring out what architecture your process was built to run on. >> user id: >> ps returns a user name, but ProcessInfo expects a numeric user ID. Examples >> of user names are u0_a306, u0_a84, root, bluetooth, etc. Generally there's a >> new user name when an apk runs IIRC. Should we include a user name field in >> ProcessInfo for these cases? > > No, we should try and figure out the user ID for the user name if possible. > The platform code has code to get the username for a user ID. +1 >> process name: >> ProcessInfo stores its process name as a FileSpec, which does path >> splitting by / or \. For some problematic system processes, ps shows a >> process name between brackets like [irq/159-arm-smm]. The FileSpec file will >> try to parse it as an actual path and the output of the process list command >> will just include 159-arm-smm]. >> I imagine that it's reasonable to discard all the processes that have names >> between brackets. > > Not sure. Maybe we can get some info from the /proc/<pid>/maps to find the > file for the process? We do want to get the process' main binary in the > process info. Anything that we don't want to attach to and debug can be left > off this list. Not sure if that means any process those name starts with a > '[' character or not? It might be worth not storing process names as FileSpecs? I think it could be a good idea to have a platform-specific method of finding the executable you want to attach to, even if its the case that most platforms will just have the binary as the process' main binary. Android, for example, might have the app's name as the name (com.foo.bar) meaning that FileSpec might be insufficient here. Also, my understanding is that process names with brackets like that are generally system services or processes that the kernel has running. Most people probably can't debug these under normal circumstances. >> long process list: >> Should we discard system and root processes? These are a lot (hundreds on >> my devices) and can't be debugged. > > Probably best to only show things we can attach to. Not sure how to weed this > out. If the lldb-server in platform mode _is_ running as root, we probably > want to show the root processes maybe? Normally we show processes that the > lldb-server user ID has access to, but this falls down real quick with > Android since each app has its own user ID. Not sure what the best option is > here. If you're running as root (which you might be if you have a rooted device) you probably want to see root's processes. I'm unsure if there is an actual good way of filtering processes here. Discarding system seems relatively safe to me here, but beyond that it's hard to say. I generally think lldb should err on the side of showing things that you won't need rather than not showing things that you might need. Weeding out things that you can't attach to is going to be kind of complicated. I think that you can have heuristics that help (e.g. can't attach to root processes if you're not root) but there's probably not a nice surefire way of doing it. :( Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D68048/new/ https://reviews.llvm.org/D68048 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
