Skip to content

Get lhs_object from byte_extract for goto trace #4480

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.

Sign up for GitHub

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

Merged
merged 1 commit into from
Apr 4, 2019
+46 −0
Merged

Get lhs_object from byte_extract for goto trace #4480

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 14 additions & 0 deletions regression/cbmc/xml-trace/main.c
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,14 @@
#include <assert.h>
#include <stdint.h>

union myunion {
int64_t i;
double d;
};

void test(union myunion u)
{
u.i += 1;
double d = u.d;
assert(d != 5);
}
25 changes: 25 additions & 0 deletions regression/cbmc/xml-trace/test.desc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
CORE broken-smt-backend
main.c
--xml-ui --function test --little-endian
^EXIT=10$
^SIGNAL=0$
VERIFICATION FAILED
<assignment assignment_type="state" base_name="u" display_name="test::u" hidden="false" identifier="test::u" mode="C" step_nr="\d+" thread="0">
<location file=".*" function="test" line="\d+" working-directory=".*"/>
<type>union myunion</type>
<full_lhs>byte_extract_little_endian\(u, 0ll?, .*int.*\)</full_lhs>
<full_lhs_value>\d+ll?</full_lhs_value>
<value>\{ \.i=\d+ll? \}</value>
<value_expression>
<union>
<member member_name="i">
<integer binary="\d+" c_type=".*int.*" width="\d+">\d+</integer>
</member>
</union>
</value_expression>
</assignment>
--
^warning: ignoring
--
Tests whether the assignment XML output contains all the required elements
such as identifier, full_lhs, full_lhs_value and value.
7 changes: 7 additions & 0 deletions src/goto-programs/goto_trace.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,6 +16,7 @@ Author: Daniel Kroening
#include <ostream>

#include <util/arith_tools.h>
#include <util/byte_operators.h>
#include <util/format_expr.h>
#include <util/range.h>
#include <util/string_utils.h>
Expand All @@ -35,6 +36,12 @@ static optionalt<symbol_exprt> get_object_rec(const exprt &src)
return get_object_rec(to_index_expr(src).array());
else if(src.id()==ID_typecast)
return get_object_rec(to_typecast_expr(src).op());
else if(
src.id() == ID_byte_extract_little_endian ||
src.id() == ID_byte_extract_big_endian)
{
return get_object_rec(to_byte_extract_expr(src).op());
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remind me, do we actually consider the offset? What you propose is consistent with what's done for index and member expressions, but I'm still wondering whether the overall result is meaningful.

Copy link
Member Author

@peterschrammel peterschrammel Apr 3, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, it was not considered. The meaningfulness is questionable, but that probably goes beyond this fix.
It might be good to actually specify what these fields are supposed to mean precisely.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here's an example to validate:

#include <assert.h>

int main()
{
  int x;
  char *p = (char *)&x + 2;
  *p = 1;
  assert(x == 0);
}

The trace currently includes byte_extract_little_endian(x, 2l, char)=1 (00000001) - which might not be downstream-consumable, but at least is accurate. If after this PR the result is x=1 then there's a problem I'm afraid.

Copy link
Member

@kroening kroening Apr 4, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

goto_trace_steps offer two bits of information:

  1. The thing returned by get_lhs_object() -- that is the object as defined in the C standard, and x is the right answer.
  2. The full_lhs, which is documented to be "after dereferencing". It is supposed to be exactly what gets assigned. The byte_extract expression above is the best answer for that, in my view.

The trace given to the user should show the latter. We may wish to print byte_extract expressions there as a pointer typecast plus dereferencing.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for clarifying! +1 for printing byte_extract as some C expression, which will be important for SV-COMP as well. But I accept that this might be outside the scope of this PR.

}
else
return {}; // give up
}
Expand Down