the test case “test_step_over_with_dwarf_python” for unit test
"functionalities/step-avoids-no debug” passes when compiling the unit test with
clang and fails when compiling with gcc, when i run the unit test in linux
(ubuntu 14.04). note: to run this test case in linux, you have to comment
out the “@skipIfLinux # intermittent failure” line.
the failure happens when the python code in TestStepNoDebug.py does the first
self.thread.StepOut() after the breakpoint.
this appears to be caused by gcc generating significantly different code than
clang. clang associates 20 bytes of machine code (all of the machine code
related to the source line) to the breakpoint source line (line 12), but gcc
only associates the first 3 bytes of machine code to line 12. gcc associates
the remaining bytes related to line 12 with line 13. the corresponding code
for both versions is shown at the bottom of this email.
this difference means that when the self.thread.StepOut() is executed in the
clang version, the program steps to the source line of the calling routine
(line 19), but the gcc version steps to the next source line (line 13). this
mismatch causes TestStepNoDebug.py to report a failure not really caused by
lldb, but really just a compiler difference.
it seems like the tests in TestStepNoDebug.py should be rewritten to include
different tests for clang and gcc, or the test should be restructured to not
rely on compiler differences - at least not clang and gcc differences.
shown below is the objdump for the clang version. the 20 bytes from 40055c
thru 40056f (inclusive) are associated with source line 12 (no bytes are
associated with source line 13).
int
called_from_nodebug_actual(int some_value)
{
400530: 55 push %rbp
400531: 48 89 e5 mov %rsp,%rbp
400534: 48 83 ec 10 sub $0x10,%rsp
400538: 48 b8 d4 06 40 00 00 movabs $0x4006d4,%rax
40053f: 00 00 00
400542: 89 7d fc mov %edi,-0x4(%rbp)
int return_value = 0;
400545: c7 45 f8 00 00 00 00 movl $0x0,-0x8(%rbp)
return_value = printf ("Length: %d.\n", some_value);
40054c: 8b 75 fc mov -0x4(%rbp),%esi
40054f: 48 89 c7 mov %rax,%rdi
400552: b0 00 mov $0x0,%al
400554: e8 b7 fe ff ff callq 400410 <printf@plt>
400559: 89 45 f8 mov %eax,-0x8(%rbp)
return return_value; // Stop here and step out of me
40055c: 8b 45 f8 mov -0x8(%rbp),%eax
40055f: 48 83 c4 10 add $0x10,%rsp
400563: 5d pop %rbp
400564: c3 retq
400565: 66 66 2e 0f 1f 84 00 data32 nopw %cs:0x0(%rax,%rax,1)
40056c: 00 00 00 00
0000000000400570 <called_from_nodebug>:
}
shown below is the objdump for the gcc version. the 3 bytes from 400556 thru
400558 (inclusive) are associated with source line 12, and the 2 bytes from
400559 thru 40055a (inclusive) are associated with source line 13.
called_from_nodebug_actual(int some_value)
{
40052d: 55 push %rbp
40052e: 48 89 e5 mov %rsp,%rbp
400531: 48 83 ec 20 sub $0x20,%rsp
400535: 89 7d ec mov %edi,-0x14(%rbp)
int return_value = 0;
400538: c7 45 fc 00 00 00 00 movl $0x0,-0x4(%rbp)
return_value = printf ("Length: %d.\n", some_value);
40053f: 8b 45 ec mov -0x14(%rbp),%eax
400542: 89 c6 mov %eax,%esi
400544: bf 94 06 40 00 mov $0x400694,%edi
400549: b8 00 00 00 00 mov $0x0,%eax
40054e: e8 bd fe ff ff callq 400410 <printf@plt>
400553: 89 45 fc mov %eax,-0x4(%rbp)
return return_value; // Stop here and step out of me
400556: 8b 45 fc mov -0x4(%rbp),%eax
}
400559: c9 leaveq
40055a: c3 retq
000000000040055b <called_from_nodebug>:
doug
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
