[Debug Info] Wrong column numbers come from macros

Hi,

I see an issue with debug info and macro. Here is an example:

#define f(x) x

int a = f(b + c);
^

The debug information for each node in ‘b + c’ points to the ‘f’ (see the caret). I expect it to point to the actual source location.

I assume that is a known issue, but I could find neither explanation nor bug report.
Can somebody shed some light on the issue?

Cheers,
Alex.

I think it’s a matter of this being the best of no great options available in DWARF, but I personally haven’t given it a great deal of thought.

This is not even a limitation of DWARF but rather mandated by the C specification. The C language standard explicitly specifies that all code in a (multi-line) macro expansion shall behave as if it were on the same line as the macro invocation. I understand that it technically doesn’t say anything about columns and perhaps we could do something for single-line macros there, but this is basically the root of the issue.

– adrian

Not sure I follow there, though, Adrian - the semantics don’t dictate just how we could model this in a debugger… (similarly how our diagnostics can provide more detail rather than modelling a macro expansion as though it was all written at the macro invocation point)

I think we’ve talked about using something like inlining to represent macro expansions, for example - to provide help with the debugging experience.

Not sure I follow there, though, Adrian - the semantics don’t dictate just how we could model this in a debugger… (similarly how our diagnostics can provide more detail rather than modelling a macro expansion as though it was all written at the macro invocation point)

I think we’ve talked about using something like inlining to represent macro expansions, for example - to provide help with the debugging experience.

Something like this would certainly be doable, but I’m somewhat concerned that we wouldn’t be able to reproduce a compilation from preprocessed source any more. I suppose we could extend #line with inline information to reflect the macro expansion, though.

– adrian

Not sure I follow there, though, Adrian - the semantics don’t dictate just how we could model this in a debugger… (similarly how our diagnostics can provide more detail rather than modelling a macro expansion as though it was all written at the macro invocation point)

I think we’ve talked about using something like inlining to represent macro expansions, for example - to provide help with the debugging experience.

Something like this would certainly be doable, but I’m somewhat concerned that we wouldn’t be able to reproduce a compilation from preprocessed source any more. I suppose we could extend #line with inline information to reflect the macro expansion, though.

I think that might already be true - if it’s a multi-line macro, for example, it’ll change the line numbers of the file (& result in the multiple lines of the macro being attributed to different lines, rather than all to the same line).

(& certainly if you’ve got column info on, it’ll change quite a lot)

Not sure I follow there, though, Adrian - the semantics don’t dictate just how we could model this in a debugger… (similarly how our diagnostics can provide more detail rather than modelling a macro expansion as though it was all written at the macro invocation point)

I think we’ve talked about using something like inlining to represent macro expansions, for example - to provide help with the debugging experience.

Something like this would certainly be doable, but I’m somewhat concerned that we wouldn’t be able to reproduce a compilation from preprocessed source any more. I suppose we could extend #line with inline information to reflect the macro expansion, though.

I think that might already be true - if it’s a multi-line macro, for example, it’ll change the line numbers of the file (& result in the multiple lines of the macro being attributed to different lines, rather than all to the same line).

As far as I rememeber, a multi-line macro gets expanded onto a single line.

(& certainly if you’ve got column info on, it’ll change quite a lot)

That’s might be the case, though.

– adrian

Not sure I follow there, though, Adrian - the semantics don’t dictate just how we could model this in a debugger… (similarly how our diagnostics can provide more detail rather than modelling a macro expansion as though it was all written at the macro invocation point)

I think we’ve talked about using something like inlining to represent macro expansions, for example - to provide help with the debugging experience.

Something like this would certainly be doable, but I’m somewhat concerned that we wouldn’t be able to reproduce a compilation from preprocessed source any more. I suppose we could extend #line with inline information to reflect the macro expansion, though.

I think that might already be true - if it’s a multi-line macro, for example, it’ll change the line numbers of the file (& result in the multiple lines of the macro being attributed to different lines, rather than all to the same line).

As far as I rememeber, a multi-line macro gets expanded onto a single line.

Ah, right you are!

(& certainly if you’ve got column info on, it’ll change quite a lot)

That’s might be the case, though.

nod