Code in block passed to macro has line number of macro invocation

[hsivonen]

It appears that (at least on Linux) if you pass a block of code to a macro, the line numbers for code in the block become the line of the start of the macro invocation rather than the actual lines within the block. This makes debugging hard.

Consider:

call_macro_defined_somewhere!({
  one();
  two();
  three();
});

Line reported for one(), two() and three() is the line that call_macro_defined_somewhere!({ is on. Expected line number for one() to be the line number for call_macro_defined_somewhere!({ plus one, etc.

[alexcrichton]

cc @michaelwoerister

[michaelwoerister]

At the moment, this is the intended behavior unfortunately. See #35238 for some discussion.

cc @vadimcn

[vadimcn]

@hsivonen: you can use -Zdebug-macros to turn this off.

[hsivonen]

you can use -Zdebug-macros to turn this off.

This helps thank you.

It surprises me that the other issue isn't a solved problem on the gdb/DWARF level, considering that C macros allow adjacent statements to be sourced from different places, too.

[tromey]

It surprises me that the other issue isn't a solved problem on the gdb/DWARF level, considering that C macros allow adjacent statements to be sourced from different places, too.

The rust compiler can emit DWARF saying where each line comes from and gdb should do the right thing when stepping. The keyword to look for in the DWARF standard is DW_LNS_set_file. Also, FWIW, I think there is at least one other bug open about debuginfo and macros. #35238 talks about pretending that macros are the result of function inlining, but I don't understand why that would be necessary, or generally even desirable. I feel though that I am probably missing something.

[vadimcn]

@tromey: We wanted to be able to step over macros like println!(), which are far more common in Rust than they are in C/C++.

I found two ways of achieving that:

• tag all code produced by a macro with the location of the macro expansion site (this is what is currently implemented). Unfortunately, this means that you cannot step through the macro guts even when that's desired. (Well, you can revert to the old behavior by compiling with -Zdebug-macros).
• tag all expanded code with true source locations, but then pretend that it ended up at the expansion site as a result of inlining (which macros are a form of, actually). This would be the preferred solution, since you'd be able to step over or into as needed; however, this turned out to be impossible to express using LLVM debug metadata.

[tromey]

but then pretend that it ended up at the expansion site as a result of inlining (which macros are a form of, actually)

This is the part I don't think is desirable. Inlining implies that there is a new function scope, which isn't necessarily the case in reality. It seems like this could make debugging weird unless you take extra effort to inject variables from the function into this new scope.

I tend to think this is another area where some Rust DWARF extension would be preferable; though maybe there are other halfway solutions, like a different heuristic for what locations to emit (e.g., if the macro invocation contains significant amounts of user code, emit locations for that code from the expansion, so that stepping "works").

[vadimcn]

Inlining implies that there is a new function scope, which isn't necessarily the case in reality.

Yeah, that's basically the reason we didn't pursue this route.

I hope my PR #39678 will sufficiently address the issue with include!() and other macros like that.

[julian-seward1]

This is also a problem when profiling Rust code, at least with the
Valgrind/Callgrind/KCachegrind stack, since they (as a result of the dwarf
src loc info) wind up attributing all costs in the included file to the include
macro invokation itself, which is pretty much useless.

[michaelwoerister]

@vadimcn Didn't you add a command line flag to control how macro source locations are handled?

[julian-seward1]

@michaelwoerister yes, -Zdebug-macros does fix it. It would be nicer if this
was the default setting, though. At least from a profiling point of view, where
seeing inside the macro is important.

[vadimcn]

@julian-seward1: You scenario is exactly why I added that flag. However, I fail to see why would we want to make it the default. The change was made for the sake of sane debugging experience. Very few people want to land in the middle of a macro definition in libstd (for which we don't even emit line numbers), when trying to step over a println!() in their source.

[hsivonen]

I, too, think that -Zdebug-macros behavior should be the default. There are many non-macro cases where one wouldn't want to step into standard-library code. It seems to me that some kind of debugger-side ignore filter for the standard-library paths would be a better solution than the compiler obfuscating the location info.