Ha, ha, that was cute. The test was cleverly(?) getting the consecutive
addresses to break at by setting the first breakpoint, running to it once,
step-i-ing, then using that pc value to set the breakpoint on the consecutive
instruction, then running again. Unfortunately, OS X by default uses some
address shuffling, so the by address breakpoint was no longer next to the
symbolic address of the original breakpoint.
I fixed this by changing the test to get the instruction list and set a
breakpoint on the next instruction, which avoids all this todo. Note, that fix
relies on the place where we break not being a branch, but the code is simple
addition, so it should not branch around anything.
Jim
> On Nov 13, 2015, at 10:39 AM, Jim Ingham <jing...@apple.com> wrote:
>
> Huh, I'll go check out that test. The basic functionality works on OS X:
>
> (lldb) b s -n main
> Breakpoint 1: 21 locations.
> (lldb) run
> Process 58218 launched: 'Sketch' (x86_64)
> Process 58218 stopped
> * thread #1: tid = 0xba0159, function: main , stop reason = breakpoint 1.1
> frame #0: 0x0000000100018dc7 Sketch`main at SKTMain.m:17
> 14 }
> 15
> 16 int main(int argc, const char *argv[]) {
> -> 17 NSLog (@"Added for testing rebuilds.");
> 18 bool got_a_bool = NO;
> 19 NSString *text_to_use = @"٢٠ شباط";
> 20
> (lldb) dis -p
> Sketch`main:
> -> 0x100018dc7 <+55>: movq %rax, %rdi
> 0x100018dca <+58>: movb $0x0, %al
> 0x100018dcc <+60>: callq 0x10001d21a ; symbol stub for:
> NSLog
> 0x100018dd1 <+65>: leaq 0xa530(%rip), %rcx ;
> @Sketch.__TEXT.__ustring + 0
> (lldb) b s -a 0x100018dca
> Breakpoint 2: where = Sketch`main + 58 at SKTMain.m:17, address =
> 0x0000000100018dca
> (lldb) c
> Process 58218 resuming
> Process 58218 stopped
> * thread #1: tid = 0xba0159, function: main , stop reason = breakpoint 2.1
> frame #0: 0x0000000100018dca Sketch`main at SKTMain.m:17
> 14 }
> 15
> 16 int main(int argc, const char *argv[]) {
> -> 17 NSLog (@"Added for testing rebuilds.");
> 18 bool got_a_bool = NO;
> 19 NSString *text_to_use = @"٢٠ شباط";
> 20
>
> Jim
>
>> On Nov 13, 2015, at 2:47 AM, Tamas Berghammer <tbergham...@google.com> wrote:
>>
>> We already have a test for it in TestConsecutiveBreakpoints.py what is
>> xfail-ed on all platform because of this bug (http://llvm.org/pr23478). As
>> far as I see from the build bots the test is also failing on OSX, but it
>> might fail from a different reason then on Linux/Windows.
>>
>> On Fri, Nov 13, 2015 at 4:10 AM Zachary Turner via lldb-commits
>> <lldb-commits@lists.llvm.org> wrote:
>> Thanks! Do you think you could add a test that does specifically that? Set
>> two breakpoints back to back, even in the same function, ane ensure that the
>> second one gets hit. If your theory is right this test will fail on Windows
>> and Linux (and then we'll have to xfail it) but at least we'll have a test
>> that's isolated to the root of the problem.
>>
>> On Thu, Nov 12, 2015 at 7:47 PM Jim Ingham <jing...@apple.com> wrote:
>> Okay, I think I fixed this, the fix is: r253008. That passes cleanly on
>> Linux for me, but I don't have a windows machine handy to test.
>>
>> What was happening is that originally lldb had a bug where if you were
>> stopped on a breakpoint and then the next instruction also had a breakpoint,
>> the plan that was stepping over the breakpoint would see a stop reason of
>> "trace" so it would think it knew why it stopped and would auto-continue,
>> since that's what you do when you are doing "step over a breakpoint and keep
>> going."
>>
>> I fixed this by having the lower layers of the process plugin correct the
>> stop reason from trace to breakpoint when a trace ended up on another
>> breakpoint, but apparently Linux and Windows don't have this fix. That was
>> done a while ago, so maybe they weren't around then, I have to think about
>> that...
>>
>> Anyway, the old code in ThreadPlanStepRange had a short-cut that if we only
>> needed to go one instruction, it wouldn't do it with a breakpoint, but just
>> stepi. I didn't preserve that in the change I made, so we got into trouble.
>> So for now I just put that short-cut back.
>>
>> I wondered how this managed to cause so many Linux failures, but the OS X
>> testsuite was clean...
>>
>> Jim
>>
>>
>>
>>> On Nov 12, 2015, at 4:57 PM, Zachary Turner <ztur...@google.com> wrote:
>>>
>>> Ahh, seems it wasn't just Windows that was affected by this. Makes me feel
>>> a little better :)
>>>
>>> Posting the link to the buildbot failures here so that Jim can get full
>>> logs if it helps.
>>> http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/8391
>>>
>>> On Thu, Nov 12, 2015 at 4:37 PM Ying Chen <chy...@google.com> wrote:
>>> I reverted this patch for now.
>>> Please resubmit if you have a fix.
>>>
>>> Thanks,
>>> Ying
>>>
>>> On Thu, Nov 12, 2015 at 4:36 PM, Jim Ingham via lldb-commits
>>> <lldb-commits@lists.llvm.org> wrote:
>>> If you can debug a failing case, and do whatever step operation got you to
>>> the wrong place, then run up to that step, and do:
>>>
>>> (lldb) log enable -f <SOMEFILE> lldb step
>>>
>>> and then do the step, then send me that log plus the disassembly for the
>>> function you were stepping in and the output of:
>>>
>>> (lldb) image dump line-table <SourceFile>
>>>
>>> for the source file you were stepping in.
>>>
>>> I should be able to see from there why we were stepping to the wrong place.
>>>
>>> Jim
>>>
>>>> On Nov 12, 2015, at 4:03 PM, Zachary Turner <ztur...@google.com> wrote:
>>>>
>>>> The error messages are always different because the error message is
>>>> printed by the test. I'm going to try to load up the executable for
>>>> TestStepNoDebug in the debugger and get a disassembly and do the step
>>>>
>>>> On Thu, Nov 12, 2015 at 4:01 PM Jim Ingham <jing...@apple.com> wrote:
>>>> Is the line they stepped to - instead of the expected line - always line 0?
>>>>
>>>> Jim
>>>>
>>>>> On Nov 12, 2015, at 3:52 PM, Zachary Turner <ztur...@google.com> wrote:
>>>>>
>>>>> Hi Jim,
>>>>>
>>>>> This breaks about 12 tests on Windows. The patch looks simple, but this
>>>>> isn't really my area, is there anything I can give you to help diagnose
>>>>> what might be wrong? The following tests fail:
>>>>>
>>>>> FAIL: LLDB (suite) :: Test-rdar-9974002.py (Windows zturner-win81 8
>>>>> 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
>>>>> FAIL: LLDB (suite) :: TestDataFormatterHexCaps.py (Windows zturner-win81
>>>>> 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
>>>>> FAIL: LLDB (suite) :: TestDataFormatterNamedSummaries.py (Windows
>>>>> zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7,
>>>>> GenuineIntel)
>>>>> FAIL: LLDB (suite) :: TestDataFormatterPythonSynth.py (Windows
>>>>> zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7,
>>>>> GenuineIntel)
>>>>> FAIL: LLDB (suite) :: TestDataFormatterSynth.py (Windows zturner-win81 8
>>>>> 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
>>>>> FAIL: LLDB (suite) :: TestDiamond.py (Windows zturner-win81 8 6.2.9200
>>>>> AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
>>>>> FAIL: LLDB (suite) :: TestFormatPropagation.py (Windows zturner-win81 8
>>>>> 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
>>>>> FAIL: LLDB (suite) :: TestFrames.py (Windows zturner-win81 8 6.2.9200
>>>>> AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
>>>>> FAIL: LLDB (suite) :: TestInlineStepping.py (Windows zturner-win81 8
>>>>> 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
>>>>> FAIL: LLDB (suite) :: TestSBData.py (Windows zturner-win81 8 6.2.9200
>>>>> AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
>>>>> FAIL: LLDB (suite) :: TestStepNoDebug.py (Windows zturner-win81 8
>>>>> 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
>>>>> FAIL: LLDB (suite) :: TestThreadJump.py (Windows zturner-win81 8 6.2.9200
>>>>> AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
>>>>>
>>>>> And here's the error I get from one of the failing tests, although I
>>>>> don't know how much insight it provides.
>>>>>
>>>>> Traceback (most recent call last):
>>>>> File
>>>>> "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\lldbtest.py", line
>>>>> 536, in wrapper
>>>>> return func(self, *args, **kwargs)
>>>>> File
>>>>> "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\lldbtest.py", line
>>>>> 2228, in dwarf_test_method
>>>>> return attrvalue(self)
>>>>> File
>>>>> "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\lldbtest.py", line
>>>>> 608, in wrapper
>>>>> func(*args, **kwargs)
>>>>> File
>>>>> "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\step-avoids-no-debug\TestStepNoDebug.py",
>>>>> line 41, in test_step_in_with_python
>>>>> self.do_step_in_past_nodebug()
>>>>> File
>>>>> "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\step-avoids-no-debug\TestStepNoDebug.py",
>>>>> line 105, in do_step_in_past_nodebug
>>>>> self.hit_correct_line ("intermediate_return_value =
>>>>> called_from_nodebug_actual(some_value)")
>>>>> File
>>>>> "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\step-avoids-no-debug\TestStepNoDebug.py",
>>>>> line 57, in hit_correct_line
>>>>> self.assertTrue (cur_line == target_line, "Stepped to line %d instead
>>>>> of expected %d with pattern '%s'."%(cur_line, target_line, pattern))
>>>>> AssertionError: False is not True : Stepped to line 0 instead of expected
>>>>> 19 with pattern 'intermediate_return_value =
>>>>> called_from_nodebug_actual(some_value)'.
>>>>> Config=i686-d:\src\llvmbuild\ninja_release\bin\clang.exe
>>>>> Session info generated @ Thu Nov 12 15:44:43 2015
>>>>> To rerun this test, issue the following command from the 'test' directory:
>>>>>
>>>>> If it's not obvious what the problem is, can we revert this until we
>>>>> figure it out and then reland it?
>>>>>
>>>>> On Thu, Nov 12, 2015 at 2:34 PM Jim Ingham via lldb-commits
>>>>> <lldb-commits@lists.llvm.org> wrote:
>>>>> Author: jingham
>>>>> Date: Thu Nov 12 16:32:09 2015
>>>>> New Revision: 252963
>>>>>
>>>>> URL: http://llvm.org/viewvc/llvm-project?rev=252963&view=rev
>>>>> Log:
>>>>> Another little stepping optimization: if any of the source step commands
>>>>> are running through a range
>>>>> of addresses, and the range has no branches, instead of running to the
>>>>> last instruction and
>>>>> single-stepping over that, run to the first instruction after the end of
>>>>> the range. If there
>>>>> are no branches in the current range, then the bytes right after it have
>>>>> to be in the current
>>>>> function, and have to be instructions not data in code, so this is safe.
>>>>> And it cuts down one
>>>>> extra stepi per source range step.
>>>>>
>>>>> Incidentally, this also works around a bug in the llvm Intel assembler
>>>>> where it treats the "rep"
>>>>> prefix as a separate instruction from the repeated instruction. If that
>>>>> were at the end of a
>>>>> line range, then we would put a trap in place of the repeated
>>>>> instruction, which is undefined
>>>>> behavior. Current processors just ignore the repetition in this case,
>>>>> which changes program behavior.
>>>>> Since there would never be a line range break after the rep prefix,
>>>>> always doing the range stepping
>>>>> to the beginning of the new range avoids this problem.
>>>>>
>>>>> <rdar://problem/23461686>
>>>>>
>>>>> Modified:
>>>>> lldb/trunk/source/Target/ThreadPlanStepRange.cpp
>>>>>
>>>>> Modified: lldb/trunk/source/Target/ThreadPlanStepRange.cpp
>>>>> URL:
>>>>> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/ThreadPlanStepRange.cpp?rev=252963&r1=252962&r2=252963&view=diff
>>>>> ==============================================================================
>>>>> --- lldb/trunk/source/Target/ThreadPlanStepRange.cpp (original)
>>>>> +++ lldb/trunk/source/Target/ThreadPlanStepRange.cpp Thu Nov 12 16:32:09
>>>>> 2015
>>>>> @@ -390,12 +390,19 @@ ThreadPlanStepRange::SetNextBranchBreakp
>>>>> if (branch_index == UINT32_MAX)
>>>>> {
>>>>> branch_index = instructions->GetSize() - 1;
>>>>> + InstructionSP last_inst =
>>>>> instructions->GetInstructionAtIndex(branch_index);
>>>>> + size_t last_inst_size = last_inst->GetOpcode().GetByteSize();
>>>>> + run_to_address = last_inst->GetAddress();
>>>>> + run_to_address.Slide(last_inst_size);
>>>>> + }
>>>>> + else if (branch_index - pc_index > 1)
>>>>> + {
>>>>> + run_to_address =
>>>>> instructions->GetInstructionAtIndex(branch_index)->GetAddress();
>>>>> }
>>>>>
>>>>> - if (branch_index - pc_index > 1)
>>>>> + if (run_to_address.IsValid())
>>>>> {
>>>>> const bool is_internal = true;
>>>>> - run_to_address =
>>>>> instructions->GetInstructionAtIndex(branch_index)->GetAddress();
>>>>> m_next_branch_bp_sp =
>>>>> GetTarget().CreateBreakpoint(run_to_address, is_internal, false);
>>>>> if (m_next_branch_bp_sp)
>>>>> {
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> lldb-commits mailing list
>>>>> lldb-commits@lists.llvm.org
>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>>>>
>>>
>>> _______________________________________________
>>> lldb-commits mailing list
>>> lldb-commits@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>>>
>>
>> _______________________________________________
>> lldb-commits mailing list
>> lldb-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
