Include column info in debuginfo

[est31]

I think that we should include column info in debuginfo, so that backtraces become more informative.

Often you do multiple function calls on a line, like ctr = ctr.inc().inc(); or let foo = wrap((), wrap((),())).

If one of these function calls generates a panic or something else that causes a backtrace, you can't know immediately which of the function calls actually caused the issue.

Apparently, right now we are setting the column number to zero: ae66285

The reason seems to be that GCC/Clang don't emit column numbers either and apparently GDB had issues with it. See #9641 and #10966. However, the change was from 2013, and maybe GDB support has changed since. Also, maybe if we ask kindly, GDB could consider adding support. AFAIK we already ship our copy of GDB so we might not even have to wait for a release to enable this per default.

Note that this is separate from panic locations, which doesn't use the LLVM debug info system but uses our own system instead. I'm preparing a PR to add line number info for panic's (without the RUST_BACKTRACE input) and want to file it soon. EDIT: #42938

cc @eddyb @michaelwoerister

[sfackler]

We don't ship a GDB - just a wrapper that loads some python scripts into the system GDB.

[michaelwoerister]

Does clang emit column information these days? If so, it should be fine to turn it on in rustc too.

[tromey]

I don't think gdb should have any particular problem with columns -- it currently just ignores them.

[est31]

I've dug a little and it seems that Visual Studio expects column info to be in ranges, and otherwise is buggy... That's why it was apparently disabled for clang+msvc: https://reviews.llvm.org/rL279765 . LLVM seems to have no way of sending column ranges, so we can't improve on clang here unless we want to patch LLVM.

However, for other targets it should work... at least worth a try.

[est31]

Sooo I've had another look and it seems that clang outputs col info by default while gcc does not, at least for the x86_64-unknown-linux-gnu target family.

Test setup

a.c source code:

#include<stdio.h>

int main() {
	printf("Hello World0\n"); printf("Hello World1\n"); printf("Hello World2\n");
	printf("Hello World3\n");
	return 0;
}

Both compiled with $CC -g a.c. Then I did cargo run --example dwarfdump -- -l /path/to/a.out with the gimli dwarfdumper.

I got this for gcc:

Line Number Rows:
<pc>        [lno,col]
0x0000063a  [   3, 0] NS uri: "/path/to/a.c"
0x0000063e  [   4, 0] NS
0x00000662  [   5, 0] NS
0x0000066e  [   6, 0] NS
0x00000673  [   7, 0] NS
0x00000675  [   7, 0] NS ET

I got this for clang:

Line Number Rows:
<pc>        [lno,col]
0x004004d0  [   3, 0] NS uri: "/path/to/a.c"
0x004004e9  [   4, 2] NS PE
0x004004fa  [   4,28]
0x0040050e  [   4,54]
0x00400522  [   5, 2] NS
0x0040052e  [   6, 2] NS
0x00400539  [   6, 2] NS ET