[LLVMdev] -gcolumn-info and PR 14106

[Eric Christopher]

On Thu, Jun 26, 2014 at 12:39 PM, Robinson, Paul
<Paul_Robinson at playstation.sony.com> wrote:
> The main motivation for turning it off is that no known consumer (debugger)
> took advantage of it.
>

There are lots of non-debugger consumers of debug info, and now we've
got cases where we actively want it for those.

> Turning it on does more than slightly increase the object file size, it can
> cause the same source line to be listed multiple times in the .debug_line
> table (with different column numbers).  This can be confusing to debuggers
> that ignore column info, or possibly to the users who expect “set breakpoint
> on line 12” to set one breakpoint and it actually sets 4. “How come nothing
> happens when I hit Continue?”
>

Honestly IMO this is a "please fix your debugger, it has bugs" issue.

-eric

> Or it can affect single-stepping, which might stop at the next
> “is-statement” entry, even if the line hasn’t changed. “How come I have to
> hit Step 4 times to get it to go to the next line?”
>
>
>
> For –Rpass and related uses, it might be useful to distinguish between
> _tracking_ column numbers and _emitting_ column numbers. IIUC –Rpass wants
> column info tracked during compilation so it can show the things it wants to
> show with maximum relevance. Whether those column numbers actually make it
> into the .debug_line section is a different story.
>
> --paulr
>
>
>
>
>
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
> Behalf Of Diego Novillo
> Sent: Thursday, June 26, 2014 9:46 AM
> To: LLVM Developers Mailing List; Eric Christopher; David Blaikie;
> octoploid at yandex.com; craig.topper at gmail.com; Chris Lattner
> Subject: [LLVMdev] -gcolumn-info and PR 14106
>
>
>
> For -Rpass, and other related uses, I am looking at enabling column info by
> default. David pointed me at PR 14106, which seems to be the original
> motivation for introducing -gcolumn-info. However, I am finding no
> differences when using it on this test.  I've tried building with/without
> -gcolumn-info and found almost no difference in compile time (+0.4%):
>
>
>
> $ /usr/bin/time clang -w -fno-builtin -O2 -g -gcolumn-info test-tgmath2.i
>
> 474.38user 2.10system 7:58.00elapsed 99%CPU
>
>
>
> $ /usr/bin/time clang -w -fno-builtin -O2 -g  test-tgmath2.i
>
> 472.63user 2.02system 7:56.11elapsed 99%CPU
>
>
>
> I'm running clang from trunk @211693.
>
>
>
> The size of all debug sections (according to readelf) are:
>
>
>
> - with -g -gcolumn-info: 836,177 bytes
>
> - with -g: 826,552 bytes
>
>
>
> That's a growth of about 1% in debug info size.
>
>
>
> These numbers are in line with a comparative build I did of our internal
> codebase. The build included a massive number of C and C++ files. For C
> files, total file size grows by 1% on average. For C++ files the average
> growth is around 0.2%. Build times are unchanged as well.
>
>
>
> Does anyone remember any other edge case I may want to try? It seems to me
> that these differences are not really worth the effort of having a flag
> controlling column information.
>
>
>
>
>
> Thanks.  Diego.