Debug info for constants have no line information

[dwblaikie]

Bugzilla Link	14501
Version	unspecified
OS	All
Blocks	#14702 llvm/llvm-bugzilla-archive#24345
CC	@DougGregor,@echristo,@fredriss,@sunfishcode,@pogo59

Extended Description

GDB 7.5 test suite's gdb.pytho/python.exp tests a fairly specific case:

int func() {
func2();
return 0;
}

break at line 2 (the call to func2)
step into func2
go up (gdb "up" command) one frame
print the line of the pc ("python print gdb.find_pc_line(gdb.selected_frame().pc()).line")

The instruction following the func2 call is assigned to the same line as "return 0" in GCC's debug info. In Clang's debug info this line has no debug info of its own, so it is on the same line as the prior instruction (the call to func2).

Subtle/may or may not be an important issue, but this might be as good a place as any to start thinking about/tracking how Clang's fast isel constant emission may be adversely impacting debugging.

[pogo59]

I had provided a patch a while back, for this very situation.
Eric didn't like it, and tried to implement the same thing a different way.
But that caused hundreds of gdb 7.2 failures (that's the suite I have).
So he reverted his patch, and that's where things stand today.

Should I post my patch again?

[echristo]

No, I've still got it. I dislike heuristics for this sort of thing, in this case it's not a prologue issue necessarily either.

[pogo59]

What heuristics?

The simplified model of fast-isel has it emitting contiguous sets
of instructions associated with statements in the (sub-)block,
which means the top of the block is associated with the first
source statement for the block.

Factoring out local-value instructions to the top of the sub-block
caused aberrant stepping behavior, which was addressed (not fixed)
by a heuristic of zapping the source loc for those instructions.
This caused the top of the sub-block to be associated with the
source line for the end of the physically preceding block, which
is not quite as aberrant but still not always smooth.

My patch restored the original source-line sequencing, i.e. the
top of the sub-block is associated with the first source line in
the block. I don't consider this to be a heuristic.

I suppose the bit about entry blocks could be a heuristic; I didn't take
the time to fully understand what's going on there. But the rest of it
is straight preservation of the existing association of source locs
with instructions.

[dwblaikie]

Worked around this again in r169998

[pogo59]

*** Bug llvm/llvm-bugzilla-archive#28596 has been marked as a duplicate of this bug. ***

[llvmbot]

mentioned in issue llvm/llvm-bugzilla-archive#24345

[pogo59]

mentioned in issue llvm/llvm-bugzilla-archive#28596

[llvmbot]

@llvm/issue-subscribers-debuginfo

Author: David Blaikie (dwblaikie)

| | | | --- | --- | | Bugzilla Link | [14501](https://llvm.org/bz14501) | | Version | unspecified | | OS | All | | Blocks | llvm/llvm-project#14702 llvm/llvm-bugzilla-archive#24345 | | CC | @DougGregor,@echristo,@fredriss,@sunfishcode,@pogo59 |

Extended Description

GDB 7.5 test suite's gdb.pytho/python.exp tests a fairly specific case:

int func() {
func2();
return 0;
}

break at line 2 (the call to func2)
step into func2
go up (gdb "up" command) one frame
print the line of the pc ("python print gdb.find_pc_line(gdb.selected_frame().pc()).line")

The instruction following the func2 call is assigned to the same line as "return 0" in GCC's debug info. In Clang's debug info this line has no debug info of its own, so it is on the same line as the prior instruction (the call to func2).

Subtle/may or may not be an important issue, but this might be as good a place as any to start thinking about/tracking how Clang's fast isel constant emission may be adversely impacting debugging.