r177164 - Force column info only for direct inlined functions. This should strike

[David Blaikie]

On Fri, Mar 15, 2013 at 10:46 AM, Adrian Prantl <aprantl at apple.com> wrote:
>
> On Mar 15, 2013, at 10:25 AM, David Blaikie <dblaikie at gmail.com> wrote:
>
>> On Fri, Mar 15, 2013 at 10:09 AM, Adrian Prantl <aprantl at apple.com> wrote:
>>> Author: adrian
>>> Date: Fri Mar 15 12:09:05 2013
>>> New Revision: 177164
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=177164&view=rev
>>> Log:
>>> Force column info only for direct inlined functions. This should strike
>>> the balance between expected behavior and compatibility with the gdb
>>> testsuite.
>>>
>>> (GDB gets confused if we break an expression into multiple debug
>>> stmts so we enable this behavior only for inlined functions. For the
>>> full experience people can still use -gcolumn-info.)
>>
>> I'm not sure I understand how this will address the issue... Perhaps
>> I'm misunderstanding something about this change. I have a few
>> questions/uncertainties:
>
>> 1) You can't really determine in the frontend if a function will
>> actually be inlined - trying to predicate debug info on that seems
>> like we'll get surprising/varying debug behavior based on whether the
>> backend chooses to inline the function
>
> That is correct. My thinking was that the backend would only inline at >O0 and if you need more precise debug info you could always use -gcolumn-info. But for those cases where function is inlined at O0 (which happens for inline-attributed functions and is done by the frontend) users will get the expected behavior.
> This is not very elegant, but I’m trying to find a middle ground between not breaking gdb’s testsuite and fixing the debug experience for inlined functions.

Sure - I'm not suggesting that we should not fix the original bug you
set out to fix, just that the solution that Eric & I were
discussing/suggesting wasn't what you've implemented here. I thought
what we were discussing was changing the backend to not emit separate
line table entries when the line is the same but the column is
different. This would be consistent with the debug experience users
expect (given GDB's lack of column information) in all cases, no
matter what things were inlined or not inlined, if I'm not mistaken.

>> 2) If the backend doesn't inline these functions you'll still get the
>> same problematic behavior from GDB (stepping back to the function call
>> between calls to foo and bar in func(foo(), bar())), won't you?
>
> You mean if the backend inlines the functions as opposed to the fronted? In this case, yes. But that would only happen at >O0 and my assumption was that we cannot guarantee a perfect debug behavior in optimized code anyway. In any case, the debug info will be correct, it just may be more detailed than gdb expects :-)
>
> — adrian