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

[Doug Snyder]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140723/7fa4ac8e/attachment.html>