[PATCH] D83468: [Debuginfo] Fix for PR46653

David Blaikie via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Aug 19 11:03:45 PDT 2020


dblaikie added a comment.

In D83468#2226596 <https://reviews.llvm.org/D83468#2226596>, @aemerson wrote:

> In D83468#2226466 <https://reviews.llvm.org/D83468#2226466>, @Jac1494 wrote:
>
>>> I would consider this to be more of a bug in GDB. Line 0 has a well-defined meaning in DWARF and stands for "no source location corresponds to this code". LLDB, for example, interprets line 0 as an indicator to skip over instructions and automatically steps over them when single-stepping through a program, since line 0 is not a meaningful place to stop. It might be worth talking to the GDB developers and ask them what they think about adding a similar feature to their handling of line 0. DWARF doesn't prescribe that that's how debuggers should behave, but I think it's a reasonable interpretation.
>>
>> @aprantl I understand line zero meaning in DWARF standard. 
>> But could you please explain that why this behavior is there with only with Global-isel enabled and NOT with SelectionDAG/FastIsel...? 
>> I mean when selection/fast-isel is enabled this not seen when using GDB. That suggest bug in global-isel not in GDB...?
>
> GlobalISel is a different instruction selection framework to SelectionDAG. Therefore, it can make different decisions and generate different code. That does not necessarily imply that there's a bug in GlobalISel, it may just be exposing an existing issue.

Also possible it's not a bug at all & GlobalISel just ends up doing some optimization that does end up creating a necessary/correct line 0 at the start of the function where SelectionDAG/FastISel does not.

Best to look at the assembly/optimizations/etc and see why it's getting line zero and decide whether it's dropping a usable location, or doing the right thing with line 0.

And, in any case, at the moment it's intentional that LLVM can produce line 0 both at the start of a function/end of the prologue and elsewhere. So if some debuggers have problems with line zero - I think at least at a first pass, it's worth pushing back a bit on changing LLVM and pushing towards changing the DWARF Consumers to handle line zero better (even if these particular line zeros turn out to be bugs/missed location opportunities - they won't be the only ones/not all of them will be bugs). If someone came back and told me GDB would not accept patches to improve line zero handling - then I think we could have a discussion about how to modify LLVM's output under a flag (-ggdb or others) to be more GDB-compatible.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D83468/new/

https://reviews.llvm.org/D83468



More information about the llvm-commits mailing list