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

[Todd Fiala]

Great!


On Wed, Jul 23, 2014 at 9:38 AM, Doug Snyder <dsnyder at blueshiftinc.com>
wrote:

> that's worth a try.
>
> i'll work on that this morning
>
>
>
>
> On Wed, Jul 23, 2014 at 9:11 AM, Todd Fiala <tfiala at google.com> wrote:
>
>> Hey I wonder if we can solve this using your thought on making it
>> compiler agnostic, by having lldb use a "step out" rather than a "step" at
>> that point?  I would hope the debugger can manage to step out of the
>> function doing that approach regardless of the "number of steps" it would
>> take to do it with a gcc vs. clang exe.
>>
>> Just a thought.  That would avoid needing separate paths for gcc and
>> clang.
>>
>> Otherwise, it for sure seems like the current test flow would need to
>> change based on compiler.  I like going with the first approach, if that's
>> valid, so we can avoid having (say) yet another compiler do something else
>> which requires yet a different path.
>>
>> -Todd
>>
>>
>> On Tue, Jul 22, 2014 at 5:30 PM, Doug Snyder <dsnyder at blueshiftinc.com>
>> wrote:
>>
>>>
>>> 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
>>>
>>>
>>> _______________________________________________
>>> lldb-dev mailing list
>>> lldb-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>>
>>>
>>
>>
>> --
>>  Todd Fiala | Software Engineer |  tfiala at google.com |  650-943-3180
>>
>
>


-- 
Todd Fiala | Software Engineer | tfiala at google.com | 650-943-3180
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140723/262ae39b/attachment.html>