Re: Adding a breakpoint creates three entries in the breakpoints list
Re: Adding a breakpoint creates three entries in the breakpoints list
- Subject: Re: Adding a breakpoint creates three entries in the breakpoints list
- From: email@hidden
- Date: Mon, 06 Jan 2014 12:08:52 -0800
You are probably right that ARC is in this case complicating the line table, but other things like inlining, auto-generated constructors, etc can cause this as well.
Adrian has been working on keeping the compiler from adding unnecessary line table entries for auto-generated code, and I've been adding heuristics to the debugger's breakpoint setting code to try not to set too many breakpoint locations in cases where the line table's been spammed by the compiler. I don't want to miss cases where the line of code can be entered from multiple points independently, so at first I was being pretty conservative about not setting breakpoints for some matches from the line table. Seems like over-setting breakpoints is more common and annoying than having multiple valid entry points, so in the next tools release version of lldb I made this reduction more aggressive, and only set one location on the first line table entry in a given syntactical block (also determined from the debug information.) That should reduce a lot of cases where you are getting multiple breakpoints for a given line.
When you get around to updating to the latest Ozark or Acadia tools releases see if this is any better. If not, please file a bug including the .o file that you are seeing the problem in, and the line number that is getting too many locations and the preprocessed source for that line (which you can make in Xcode with Products->Perform Action->Preprocess.)
Jim
On Dec 25, 2013, at 3:26 PM, Quincey Morris <email@hidden> wrote:
> On Dec 24, 2013, at 19:48 , Rick Mann <email@hidden> wrote:
>
>> Multiple calls happen. No macro.
>
> I’m seeing something like this too, in Obj-C source code like this:
>
>> - (NSRange) otherMethod: (NSRange) range {
>> …
>> }
>>
>> - (void) myMethod: (NSNotification*) notification {
>> NSTextView* textView = notification.object;
>> NSTextView* inputView = …;
>> NSRange range = …;
>> NSRange result = [self otherMethod: range]; // <— line 111
>> }
>
> The breakpoint is set at line 111. When I run this (Debug configuration), the breakpoint becomes *two* breakpoints at line 111 as soon as the debugger starts. When I hit the first breakpoint, it stops at address 0x100032991:
>
>> 0x100032991: movq -56(%rbp), %rdi
>> 0x100032995: movq 7165452(%rip), %rsi ; “otherMethod:"
>> 0x10003299c: movq -136(%rbp), %rdx
>> 0x1000329a3: movq 6990070(%rip), %rax ; (void *)0x00007fff8ac70080: objc_msgSend
>> 0x1000329aa: callq *%rax
>> 0x1000329ac: movq %rax, -152(%rbp)
>> 0x1000329b3: movq %rdx, -144(%rbp)
>>
>> 0x1000329ba: movl $0, -92(%rbp)
>> 0x1000329c1: leaq -88(%rbp), %rdi
>> 0x1000329c5: xorl êx, êx
>> 0x1000329c7: movq %rax, %rsi
>> 0x1000329ca: movq %rax, -200(%rbp)
>> 0x1000329d1: callq 0x10053f8e8 ; symbol stub for: objc_storeStrong
>> 0x1000329d6: leaq -80(%rbp), %rdi
>> 0x1000329da: movq -200(%rbp), %rsi
>> 0x1000329e1: callq 0x10053f8e8 ; symbol stub for: objc_storeStrong
>> 0x1000329e6: movl -92(%rbp), ìx
>> 0x1000329e9: testl ìx, ìx
>> 0x1000329eb: jne 0x1000329fd ; -[MyClass myMethod:] + 477 at MyClass.m:111
>> 0x1000329f1: jmpq 0x1000329f6 ; -[MyClass myMethod:] + 470 at MyClass.m:111
>>
>> 0x1000329f6: movl $0, -92(%rbp)
>> 0x1000329fd: leaq -72(%rbp), %rdi
>> 0x100032a01: xorl %esi, %esi
>> 0x100032a03: callq 0x10053f8e8 ; symbol stub for: objc_storeStrong
>> 0x100032a08: movl -92(%rbp), êx
>> 0x100032a0b: subl $1, êx
>> 0x100032a0e: movl êx, -204(%rbp)
>> 0x100032a14: ja 0x100032a28 ; -[MyClass myMethod:] + 520
>> 0x100032a1a: jmpq 0x100032a1f ; -[MyClass myMethod:] + 511 at MyClass.m:112
>>
>> 0x100032a1f: addq $208, %rsp
>> 0x100032a26: popq %rbp
>> 0x100032a27: ret
>
> (The blank lines aren’t in the disassembly. I inserted them to make it easier to see the relevant addresses.)
>
> After continuing, it stops at the second breakpoint, at address 0x1000329f6.
>
> Interestingly, if I step multiple times after the first breakpoint instead of continuing, then it stops an extra time: at address 0x1000329ba, then at 0x1000329f6, then finally at 0x100032a1f for the return.
>
> It looks to me like this is some side effect of ARC — the line number debug information is duplicated for ARC-related code. I assume that the three ‘objc_storeStrong’ calls are releasing the objects stored in the local variables earlier in the method.
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden