[Lldb-commits] [PATCH] D26804: Fix step-over when SymbolContext.function is missing and symbol is present.

[Jim Ingham via lldb-commits]

> On Nov 17, 2016, at 1:45 PM, Sam McCall <sammccall at google.com> wrote:
> 
> On Thu, Nov 17, 2016 at 10:29 PM, Jim Ingham <jingham at apple.com <mailto:jingham at apple.com>> wrote:
> Ah, good catch.  That is not right.  If there’s inlined function information, you want to make sure you haven’t gone from one inlined function to another.  But the symbol is always going to be the same in this case.
> OK, I've updated the patch to return false in this case.
> 
> Actually, the old code is a overly restrictive by comparing the blocks directly.  What you really want to test is that if either side is in an inlined function, both sides are still inside the same inlined function instantiation.  We should really compare the ContainingInlinedBlock of the current blocks if there is inlined info.
> Happy to take a stab at this - I'm not too familiar with the structures here so I'll read a bit and send a new patch if that's OK!

That’s fine.

Jim


> 
> This stuff is a PITA to write tests for, too, since it is hard to predict how the compiler will emit inlined code...
> 
> Jim
> 
> 
>> On Nov 17, 2016, at 1:13 PM, Sam McCall <sammccall at google.com <mailto:sammccall at google.com>> wrote:
>> 
>> Thanks. I just noticed, this also changes the behavior (now returns true) if:
>>  - comp_unit and function both match
>>  - block->GetInlinedFunctionInfo != nullptr
>>  - blocks aren't equal
>>  - symbols are equal
>> 
>> Is this correct? Otherwise I'll fix this case to match the old behavior.
>> 
>> On Thu, Nov 17, 2016 at 10:09 PM, Jim Ingham <jingham at apple.com <mailto:jingham at apple.com>> wrote:
>> jingham accepted this revision.
>> jingham added a comment.
>> This revision is now accepted and ready to land.
>> 
>> That way of doing it is fine too.
>> 
>> 
>> https://reviews.llvm.org/D26804 <https://reviews.llvm.org/D26804>
>> 
>> 
>> 
>> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20161117/c4e4aeec/attachment.html>