Skip to content
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

Closed
vitalybuka opened this issue Dec 29, 2023 · 1 comment · Fixed by #78606 or #79864
Closed

HWASAN: No DW_OP_LLVM_tag_offset with opt above -O0 #76545

vitalybuka opened this issue Dec 29, 2023 · 1 comment · Fixed by #78606 or #79864
Assignees
Labels
compiler-rt:hwasan Hardware-assisted address sanitizer llvm:transforms

Comments

@vitalybuka
Copy link
Collaborator

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.

@vitalybuka vitalybuka added compiler-rt:hwasan Hardware-assisted address sanitizer llvm:transforms labels Dec 29, 2023
@vitalybuka vitalybuka self-assigned this 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.
@jmorse
Copy link
Member

jmorse commented Jan 18, 2024

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 OCHyams reopened this Jan 29, 2024
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
Labels
compiler-rt:hwasan Hardware-assisted address sanitizer llvm:transforms
Projects
None yet
3 participants