This PR is in reference to porting LLDB on AIX. Link to discussions on llvm discourse and github: 1. https://discourse.llvm.org/t/port-lldb-to-ibm-aix/80640 2. https://github.com/llvm/llvm-project/issues/101657 The complete changes for porting are present in this draft PR: https://github.com/llvm/llvm-project/pull/102601 - Added changes to make the common host support functions under `Host/posix` for unix-like system. Also, created the `unittests/Host/posix/` to test the hostInfo & support functions for unix-like system. - Added changes to get the host information for AIX. (GetProcessInfo()) (Information like : executable path, arch, process status etc.)
This is a follow-up to D116372, which had a rather unfortunate side effect of making the processing of a single SIGCHLD quadratic in the number of threads -- which does not matter for simple applications, but can get really bad for applications with thousands of threads. This patch fixes the problem by implementing the other possibility mentioned in the first patch -- doing waitpid(-1) centrally and then routing the events to the correct process instance. The "uncollected" threads are held in the process factory class -- which I've renamed to Manager for this purpose, as it now does more than creating processes. Differential Revision: https://reviews.llvm.org/D146977
- Add collection of context switches per cpu grouped with the per-cpu intel pt traces. - Move the state handling from the interl pt trace class to the PerfEvent one. - Add support for stopping and enabling perf event groups. - Return context switch entries as part of the jLLDBTraceGetState response. - Move the triggers of whenever the process stopped or resumed. Now the will-resume notification is in a better location, which will ensure that we'll capture the instructions that will be executed. - Remove IntelPTSingleBufferTraceUP. The unique pointer was useless. - Add unit tests Differential Revision: https://reviews.llvm.org/D125897
When tracing on per-core mode, we are tracing all processes, which means that after hitting a breakpoint, our process will stop running (thus producing no more tracing data) but other processes will continue writing to our trace buffers. This causes a big data loss for our trace. As a way to remediate this, I'm adding some logic to pause and unpause tracing based on the target's state. The earlier we do it the better, however, I'm not adding the trigger at the earliest possible point for simplicity of this diff. Later we can improve that part. Differential Revision: https://reviews.llvm.org/D124962
- Rename IntelPTManager class and files to IntelPTCollector
- Change GetTimestampCounter API to general trace counter API,
GetCounter
Differential Revision: https://reviews.llvm.org/D121711
Implement the qXfer:siginfo:read that is used to read the siginfo_t (extended signal information) for the current thread. This is currently implemented on FreeBSD and Linux. Differential Revision: https://reviews.llvm.org/D117113
The lldb-server code is currently set up in a way that each NativeProcess instance does its own waitpid handling. This works fine for BSDs, where the code can do a waitpid(process_id), and get information for all threads in that process. The situation is trickier on linux, because waitpid(pid) will only return information for the main thread of the process (one whose tid == pid). For this reason the linux code does a waitpid(-1), to get information for all threads. This was fine while we were supporting just a single process, but becomes a problem when we have multiple processes as they end up stealing each others events. There are two possible solutions to this problem: - call waitpid(-1) centrally, and then dispatch the events to the appropriate process - have each process call waitpid(tid) for all the threads it manages This patch implements the second approach. Besides fitting better into the existing design, it also has the added benefit of ensuring predictable ordering for thread/process creation events (which come in pairs -- one for the parent and one for the child). The first approach OTOH, would make this ordering even more complicated since we would have to keep the half-threads hanging in mid-air until we find the process we should attach them to. The downside to this approach is an increased number of syscalls (one waitpid for each thread), but I think we're pretty far from optimizing things like this, and so the cleanliness of the design is worth it. The included test reproduces the circumstances which should demonstrate the bug (which manifests as a hung test), but I have not been able to get it to fail. The only place I've seen this failure modes are very rare hangs in the thread sanitizer tests (tsan forks an addr2line process to produce its error messages). Differential Revision: https://reviews.llvm.org/D116372
The MonitorCallback function was assuming that the "exited" argument is set whenever a thread exits, but the caller was only setting that flag for the main thread. This patch deletes the argument altogether, and lets MonitorCallback compute what it needs itself. This is almost NFC, since previously we would end up in the "GetSignalInfo failed for unknown reasons" branch, which was doing the same thing -- forgetting about the thread.
This is implemented using the QMemTags packet, as specified by GDB in: https://sourceware.org/gdb/current/onlinedocs/gdb/General-Query-Packets.html#General-Query-Packets (recall that qMemTags was previously added to read tags) On receipt of a valid packet lldb-server will: * align the given address and length to granules (most of the time lldb will have already done this but the specification doesn't guarantee it) * Repeat the supplied tags as many times as needed to cover the range. (if tags > range we just use as many as needed) * Call ptrace POKEMTETAGS to write the tags. The ptrace step will loop just like the tag read does, until all tags are written or we get an error. Meaning that if ptrace succeeds it could be a partial write. So we call it again and if we then get an error, return an error to lldb. We are not going to attempt to restore tags after a partial write followed by an error. This matches the behaviour of the existing memory writes. The lldb-server tests have been extended to include read and write in the same test file. With some updated function names since "qMemTags" vs "QMemTags" isn't very clear when they're next to each other. Reviewed By: omjavaid Differential Revision: https://reviews.llvm.org/D105180
This adds memory tag reading using the new "qMemTags" packet and ptrace on AArch64 Linux. This new packet is following the one used by GDB. (https://sourceware.org/gdb/current/onlinedocs/gdb/General-Query-Packets.html) On AArch64 Linux we use ptrace's PEEKMTETAGS to read tags and we assume that lldb has already checked that the memory region actually has tagging enabled. We do not assume that lldb has expanded the requested range to granules and expand it again to be sure. (although lldb will be sending aligned ranges because it happens to need them client side anyway) Also we don't assume untagged addresses. So for AArch64 we'll remove the top byte before using them. (the top byte includes MTE and other non address data) To do the ptrace read NativeProcessLinux will ask the native register context for a memory tag manager based on the type in the packet. This also gives you the ptrace numbers you need. (it's called a register context but it also has non register data, so it saves adding another per platform sub class) The only supported platform for this is AArch64 Linux and the only supported tag type is MTE allocation tags. Anything else will error. Ptrace can return a partial result but for lldb-server we will be treating that as an error. To succeed we need to get all the tags we expect. (Note that the protocol leaves room for logical tags to be read via qMemTags but this is not going to be implemented for lldb at this time.) Reviewed By: omjavaid Differential Revision: https://reviews.llvm.org/D95601