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 <[email protected]> wrote: > Great! > > > On Wed, Jul 23, 2014 at 9:38 AM, Doug Snyder <[email protected]> > wrote: > >> that's worth a try. >> >> i'll work on that this morning >> >> >> >> >> On Wed, Jul 23, 2014 at 9:11 AM, Todd Fiala <[email protected]> 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 <[email protected]> >>> 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@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 >>>> >>>> >>> >>> >>> -- >>> Todd Fiala | Software Engineer | [email protected] | 650-943-3180 >>> >> >> > > > -- > Todd Fiala | Software Engineer | [email protected] | 650-943-3180 >
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
