[lldb-dev] unit test "functionalities/step-avoids-no debug"

[Doug Snyder]

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 at 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 at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140722/c0108dad/attachment.html>