If we're not touching them, we don't need to do anything special to pass them along -- with one important caveat: due to how cmake arguments work, the implicitly passed arguments need to be specified before arguments that we handle. This isn't particularly nice, but the alternative is enumerating all arguments that can be used by llvm_add_library and the macros it calls (it also relies on implicit passing of some arguments to llvm_process_sources).
After some debugging, I found out ProcessELFCore never updates the platform. I've updated ProcessElfCore to set the arch and platform before we parse the Notes.
Reverts llvm/llvm-project#140150 Broke the Darwin tests, but they pass on Linux. Reverting to make the build healthy while I investigate
Recently, I was on an issue that generated a large number of Coredumps,
and every time in both LLDB and GDB the signal was just `SIGSEGV`.
This was frustrating because we would expect a `SIGSEGV` to have an
address, or ideally even bounds. After some digging I found the
`si_code` consistently was -6. With some help from
[@cdown](https://github.com/cdown), we found neither LLDB or GDB
supports the si_codes sent from [user
space](https://github.com/torvalds/linux/blob/master/include/uapi/asm-generic/siginfo.h#L185).
Excerpted from the sigaction man page.
```
For a regular signal, the following list shows the values which
can be placed in si_code for any signal, along with the reason
that the signal was generated.
```
For which I added all of the si_codes to every Linux signal. Now for the
Coredump that triggered this whole investigation we get the accurate and
now very informative summary.
<img width="524" alt="image"
src="https://github.com/user-attachments/assets/5149f781-ef21-4491-a077-8fac862fbc20"
/>
Additionally from @labath's suggestion to move this to platform and
leverage the existing `getSiginfo()` call on thread, we can now inspect
the siginfo struct itself via `thread siginfo`. Giving us another
towards GDB parity on elf cores.
Add support for riscv32 ELF corefiles.
Fix for: `Assertion failed: (false && "Architecture or OS not supported"), function CreateRegisterContextForFrame, file /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/elf-core/ThreadElfCore.cpp, line 182. PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace. #0 0x000000080cd857c8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:723:13 #1 0x000000080cd85ed4 /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:797:3 #2 0x000000080cd82ae8 llvm::sys::RunSignalHandlers() /usr/src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:104:5 #3 0x000000080cd861f0 SignalHandler /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:403:3 #4 0x000000080f159644 handle_signal /usr/src/lib/libthr/thread/thr_sig.c:298:3 `
In some core file, we are seeing that it's not always the case that the ELF header would exist in the first region in NT_FILES section. Therefore the FindModuleUUID is not able to find the module UUID by just returning the first entry with path matching. This fix change the behavior to continue search the NT_FILE entries until finding a valid UUID with path matching. Co-authored-by: George Hu <georgehuyubo@gmail.com>
This allows you to read the same registers as you would for a live process. As the content of proc/pid/smaps is not included in the core file, we don't get the "ss" marker that tell us that it is shadow stack. The GCS region is still in the list though.
This commit addresses a bug introduced in commit bcf654c, which prevented LLDB from parsing the GNU build ID for the main executable from a core file. The fix finds the `p_vaddr` of the first `PT_LOAD` segment as the `base_addr` and subtract this `base_addr` from the virtual address being read. Co-authored-by: George Hu <hyubo@meta.com>