Skip to content

Conversation

jasonmolenda
Copy link

It is possible to gather code coverage in a firmware environment, where the __LLVM_COV segment will not be mapped in memory but does exist in the binary, see

https://llvm.org/devmtg/2020-09/slides/PhippsAlan_EmbeddedCodeCoverage_LLVM_Conf_Talk_final.pdf

The __LLVM_COV segment in the binary happens to be at the same address as the __DATA segment, so if lldb treats this segment as loaded, it shadows the __DATA segment and address->symbol resolution can fail.

For these non-userland code cases, we need to mark __LLVM_COV as not a loadable segment.

rdar://124475661
(cherry picked from commit 765d4c4)

…lvm#86359)

It is possible to gather code coverage in a firmware environment, where
the __LLVM_COV segment will not be mapped in memory but does exist in
the binary, see

https://llvm.org/devmtg/2020-09/slides/PhippsAlan_EmbeddedCodeCoverage_LLVM_Conf_Talk_final.pdf

The __LLVM_COV segment in the binary happens to be at the same address
as the __DATA segment, so if lldb treats this segment as loaded, it
shadows the __DATA segment and address->symbol resolution can fail.

For these non-userland code cases, we need to mark __LLVM_COV as not a
loadable segment.

rdar://124475661
(cherry picked from commit 765d4c4)
@jasonmolenda
Copy link
Author

@swift-ci test

@JDevlieghere JDevlieghere merged commit c119195 into swiftlang:swift/release/6.0 Mar 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants