This is an archive of the discontinued LLVM Phabricator instance.

[DebugInfo] Fix multi-byte entry values in call site values
ClosedPublic

Authored by dstenb on Mar 17 2020, 6:23 AM.

Details

Summary

In D67768/D67492 I added support for entry values having blocks larger
than one byte, but I now noticed that the DIE implementation I added there
was broken. The takeNodes() function, that moves the entry value block
from a temporary buffer to the output buffer, would destroy the input
iterator when transferring the first node, meaning that only that node
was moved.

In practice, this meant that when emitting a call site value using a
DW_OP_entry_value operation with a DWARF register number larger than 31,
that multi-byte DW_OP_regx expression would be truncated.

Diff Detail

Event Timeline

dstenb created this revision.Mar 17 2020, 6:23 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 17 2020, 6:23 AM
djtodoro accepted this revision.Mar 17 2020, 7:13 AM

LGTM! Thanks!

So, this was causing the wrong call_site_value for the parameter only?

This revision is now accepted and ready to land.Mar 17 2020, 7:13 AM

LGTM! Thanks!

So, this was causing the wrong call_site_value for the parameter only?

Yes, the DW_AT_location was correct, so it was only the call site value that was incorrect.

In the attached test case the call site parameter entry would be printed as the following by llvm-dwardump:

0x0000004c:       DW_TAG_GNU_call_site_parameter
                    DW_AT_location	(DW_OP_regx B0)
                    DW_AT_GNU_call_site_value	(DW_OP_GNU_entry_value(DW_OP_regx W0)

W0 has DWARF number 0, so presumably it just used the following End of Children mark for the DW_OP_regx operand.

vsk added inline comments.Mar 17 2020, 11:01 AM
llvm/include/llvm/CodeGen/DIE.h
567

Is IntrusiveBackList a circularly linked list, with an always-available pointer to the last element? If so, this lgtm, as the loop will terminate after going 'one past' the last node.

(This is outside the scope of this patch, but: it'd be really nice to check in some doxygen for IntrusiveBackList.)

LGTM! Thanks!

So, this was causing the wrong call_site_value for the parameter only?

Yes, the DW_AT_location was correct, so it was only the call site value that was incorrect.

In the attached test case the call site parameter entry would be printed as the following by llvm-dwardump:

0x0000004c:       DW_TAG_GNU_call_site_parameter
                    DW_AT_location	(DW_OP_regx B0)
                    DW_AT_GNU_call_site_value	(DW_OP_GNU_entry_value(DW_OP_regx W0)

W0 has DWARF number 0, so presumably it just used the following End of Children mark for the DW_OP_regx operand.

OK, thanks!

dstenb marked an inline comment as done.Mar 18 2020, 3:30 AM

Thanks for the reviews! I'll land this shortly.

llvm/include/llvm/CodeGen/DIE.h
567

Yes, it is implementation-wise a circularly linked list, but it has a non-circular iterator interface.

(If I get some extra time this week, I can try to upload a patch that adds some very basic doxygen comments for the classes.)

This revision was automatically updated to reflect the committed changes.