-
Notifications
You must be signed in to change notification settings - Fork 10.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HWASAN: No DW_OP_LLVM_tag_offset with opt above -O0 #76545
Labels
Comments
vitalybuka
added
compiler-rt:hwasan
Hardware-assisted address sanitizer
llvm:transforms
labels
Dec 29, 2023
vitalybuka
added a commit
that referenced
this issue
Jan 2, 2024
Temporarily fix for issue #76545 Hwasan does not attach tags to @llvm.dbg.assign. It's not clear if we can attach tags to @llvm.dbg.assign. For now we just disable the path replacing llvm.dbg.declare with llvm.dbg.assign. It may reduce the quality of interactive debugging with HWASAN, but usually it's a smaller priority for sanitizers than the quality if reports.
Had a quick chat with @OCHyams about this; all the trickyness with assignment-tracking likely comes from it having two DIExpressions, one for "How to compute the variables value" and the other "How to compute the stack location", presumably DW_OP_llvm_tag_offset wants to be applied to the latter. We'll give it a prod shortly. |
OCHyams
added a commit
that referenced
this issue
Jan 22, 2024
llvm.dbg.assign intrinsics have 2 {value, expression} pairs; fix hwasan to update the second expression. Fixes #76545
OCHyams
added a commit
that referenced
this issue
Jan 22, 2024
llvm.dbg.assign intrinsics have 2 {value, expression} pairs; fix hwasan to update the second expression. Fixes #76545
OCHyams
added a commit
that referenced
this issue
Jan 23, 2024
llvm.dbg.assign intrinsics have 2 {value, expression} pairs; fix hwasan to update the second expression. Fixes #76545
OCHyams
added a commit
to OCHyams/llvm-project
that referenced
this issue
Jan 29, 2024
…an to update the second expression. The DWARF output looks correct (see the AArch64 tests) as far as I can tell. Fixes llvm#76545
OCHyams
added a commit
that referenced
this issue
Feb 1, 2024
…79816) According to its doc-comment `isImplicit` is meant to return true if the expression is an implicit location description (describes an object or part of an object which has no location by computing the value from available program state). There's a brief entry for `DW_OP_LLVM_tag_offset` in the LangRef and there's some info in the original commit fb9ce10. From what I can tell it doesn't look like `DW_OP_LLVM_tag_offset` affects whether or not the location is implicit; the opcode doesn't get included in the final location description but instead is added as an attribute to the variable. This was tripping an assertion in the latest application of the fix to #76545, #78606, where an expression containing a `DW_OP_LLVM_tag_offset` is split into a fragment (i.e., describe a part of the whole variable).
carlosgalvezp
pushed a commit
to carlosgalvezp/llvm-project
that referenced
this issue
Feb 1, 2024
…lvm#79816) According to its doc-comment `isImplicit` is meant to return true if the expression is an implicit location description (describes an object or part of an object which has no location by computing the value from available program state). There's a brief entry for `DW_OP_LLVM_tag_offset` in the LangRef and there's some info in the original commit fb9ce10. From what I can tell it doesn't look like `DW_OP_LLVM_tag_offset` affects whether or not the location is implicit; the opcode doesn't get included in the final location description but instead is added as an attribute to the variable. This was tripping an assertion in the latest application of the fix to llvm#76545, llvm#78606, where an expression containing a `DW_OP_LLVM_tag_offset` is split into a fragment (i.e., describe a part of the whole variable).
OCHyams
added a commit
to OCHyams/llvm-project
that referenced
this issue
Feb 5, 2024
…an to update the second expression. The DWARF output looks correct (see the AArch64 tests) as far as I can tell. Fixes llvm#76545
agozillon
pushed a commit
to agozillon/llvm-project
that referenced
this issue
Feb 5, 2024
…lvm#79816) According to its doc-comment `isImplicit` is meant to return true if the expression is an implicit location description (describes an object or part of an object which has no location by computing the value from available program state). There's a brief entry for `DW_OP_LLVM_tag_offset` in the LangRef and there's some info in the original commit fb9ce10. From what I can tell it doesn't look like `DW_OP_LLVM_tag_offset` affects whether or not the location is implicit; the opcode doesn't get included in the final location description but instead is added as an attribute to the variable. This was tripping an assertion in the latest application of the fix to llvm#76545, llvm#78606, where an expression containing a `DW_OP_LLVM_tag_offset` is split into a fragment (i.e., describe a part of the whole variable).
OCHyams
added a commit
to OCHyams/llvm-project
that referenced
this issue
Feb 12, 2024
…an to update the second expression. The DWARF output looks correct (see the AArch64 tests) as far as I can tell. Fixes llvm#76545
OCHyams
added a commit
that referenced
this issue
Feb 13, 2024
llvm.dbg.assign intrinsics have 2 {value, expression} pairs; fix hwasan to update the second expression. Fixes #76545. This is #78606 rebased and with the addition of DPValue handling. Note the addition of --try-experimental-debuginfo-iterators in the tests and some shuffling of code in MemoryTaggingSupport.cpp.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
DW_OP_LLVM_tag_offset is present in -O0, but not -O1 https://godbolt.org/z/3dj6bzz4z
Reasons is
AssignmentTrackingPass
and-instcombine-lower-dbg-declare
replace@llvm.dbg.declare
with@llvm.dbg.assign
but we don't attach DW_OP_LLVM_tag_offset to@llvm.dbg.assign
.The text was updated successfully, but these errors were encountered: