search

llvm / llvm-project

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.
http://llvm.org
Other
29.05k stars 11.98k forks source link

Debug info for constants have no line information #14873

Open dwblaikie opened 11 years ago

dwblaikie commented 11 years ago
Bugzilla Link 14501
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.

pogo59 commented 2 years ago

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

llvmbot commented 2 years ago

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

pogo59 commented 8 years ago

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

dwblaikie commented 11 years ago

Worked around this again in r169998

pogo59 commented 11 years ago

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.

echristo commented 11 years ago

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 commented 11 years ago

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?

llvmbot commented 1 year ago

@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.