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

[Adrian Prantl]

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.

> 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