[PATCH] D26632: [sanitizer] Track architecture and UUID of modules in LoadedModule

[Kuba (Brecka) Mracek via Phabricator via llvm-commits]

kubabrecka added a comment.

> How are you planning on using the ModuleArch part? Would it be better (see my inline comment) to just save the `cputype` + `cpusubtype`?

An immediate plan is to use ModuleArch for symbolication.  When you just have module name + address, that's not enough to symbolicate, because the address might be valid in multiple slices in the module file on disk.  Both atos and llvm-symbolizer suffer from this and it's especially painful on Haswell+ Intel machines, where plenty of modules (including the ASan and TSan dylibs) have both the x86_64 and x86_64h slices and basically each pointer is usually valid in both slices.  I'm simply planning to pass the arch (as a string most likely) to atos and to llvm-symbolizer and to produce this in reports (again as a string).  I don't think the CPU type+subtype is useful for this.  And the set of archs that Darwin supports is very small.  I think that type+subtype is too Mach-O specific to store it in LoadedModule.

> IIUC, you can only have a slice per arch (type+subtype?).

That's right.

> Are you planning on always relying on ModuleArch (or something similar) all the time, or only as a fallback, if no UUID is available?

I'm planning to use the ModuleArch all the time to correctly select the slice when symbolicating.

The plan for UUIDs is related, but slightly different.  We have a few requests from people who use ASan and TSan in CI and/or process the text reports in various ways.  They want to be able to pass ASan/TSan reports to symbolication servers.  All of the existing debug symbols server support on macOS relies on module UUIDs.  My plan is to have an option (maybe on by default, maybe not) that includes UUIDs of modules involved in the text report.

I'll send patches for review for this and the previously mentioned symbolication change soon.


https://reviews.llvm.org/D26632