Before this patch, llvm-xray account will assume that thread stacks will
not be empty. Unfortunately there are cases where an instrumented
function will see a call to fork() which will cause the child process
to not see the start of the function, but only see the end of the
function. The tooling cannot assume that threads will always have
perfect stacks, and so we change it to support this reality.
Details
Diff Detail
- Build Status
Buildable 9463 Build 9463: arc lint + arc unit
Event Timeline
test/tools/llvm-xray/X86/account-empty-stack-error.yaml | ||
---|---|---|
16–17 | Is the "keep going" functionality sufficiently tested? (Does this new error path present an interesting/new case of "keep going" that's worth testing separately - or is the functionality sufficiently generic that the existing testing covers enough here) |
test/tools/llvm-xray/X86/account-empty-stack-error.yaml | ||
---|---|---|
16–17 | We have a dedicated test that uses -k for account. This particular case isn't so interesting, because we're not attempting to recover or handle it (yet). In the future we may want to indicate in the accounting how many records we've discarded, how many we've deduced tail calls for, etc. -- but that's not so important at the moment than not crashing when we have this situation. |
Please read the mailing list - Phab is not authoritative and doesn't always reflect replies/content on the mailing list.
test/tools/llvm-xray/X86/account-empty-stack-error.yaml | ||
---|---|---|
16–17 | I added a test for the keep-going path as well, making sure it works in this path as well. |
ping @dblaikie -- I think I've addressed the question you had about the -keep-going mode, with an additional test.
tools/llvm-xray/xray-account.cc | ||
---|---|---|
412 | This struct doesn't appear to be used anywhere. Do we need it? |
tools/llvm-xray/xray-account.cc | ||
---|---|---|
412 | Ah, yes -- this is a specialization of a type used by the llvm::format(...) library for specifically the RecordTypes enum class. |
Is the "keep going" functionality sufficiently tested? (Does this new error path present an interesting/new case of "keep going" that's worth testing separately - or is the functionality sufficiently generic that the existing testing covers enough here)