[lldb-dev] unit test "functionalities/step-avoids-no debug"
Doug Snyder
dsnyder at blueshiftinc.com
Wed Jul 23 11:12:08 PDT 2014
in routine "do_step_over_past_debug()" in TestSteoNoDebug.py, if i change
the first and third "self.thread.StepOver()" to "self.thread.StepOut()",
test "test_step_over_with_dwarf" will pass with gcc (and not break
with clang).
however, i'm not sure if this change is bypassing the intention of
test_step_over_with_dwarf. this change may make gcc pass, but is probably
hiding suspect gcc behaviour and may break the original intention of
test_step_over_with_dwarf.
doug
On Wed, Jul 23, 2014 at 9:51 AM, Todd Fiala <tfiala at google.com> wrote:
> 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/b2b8ad16/attachment.html>
More information about the lldb-dev
mailing list