[llvm] [llvm-exegesis] [AArch64] Resolving "snippet crashed while running: Segmentation fault" for Load Instructions (PR #142552)

Aiden Grossman via llvm-commits llvm-commits at lists.llvm.org
Mon Jun 16 10:45:37 PDT 2025


boomanaiden154 wrote:

> "How is exegesis setting up the register to have correct memory address from which instruction can load value?" (if fillMemoryOperands is supposed to fill then, how?).

We don't support putting an address directly into a register in subprocess mode currently. For now you have to specify a specific address and then add add an instruction/snippet setup to set a register to that value. This has been something I've wanted to add for a while, but I've never had a need for it.

> Q1. Motivation behind munmap calls ?

Probably depends upon the specific call. Most likely just to clean things up at the end. It's probably not strictly necessary in a lot of cases.

> How is File Descriptor being managed ?

Which file descriptor? I believe there is an FD for the shared memory that is created before we fork the subprocess and thus just exists in the child. The perf counter FD needs to be created afterwards to target the PID of the subprocess. We send it to the child process through a socket to perform FD translation. There was original implementation using `pidfd_getfd`, but that's still a relatively new syscall.

> But file descriptor at this or any address seems not to populated i.e. No call for __NR_perf_event_open which init fd

It's done in the parent process and sent over. Most of the subprocess memory stuff should be handled by `SubprocessMemory`.

> configurePerfCounter calls SYS_ioctl with file descriptor at getAuxiliaryMemoryStartAddress() but seeming not initialized.

Not initialize as in you have a debugger attached and the value is zero/random or not initialize as in you can't see where it's getting initialized? The tests pass, so it's definitely getting initialized at least in some contexts.

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


More information about the llvm-commits mailing list