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
