Re: [PATCH 2/2] gdb: Preserve is-stmt lines when switch between files

[Andrew Burgess <andrew.burgess@embecosm.com>]

* Bernd Edlinger <bernd.edlinger@hotmail.de> [2020-04-25 09:06:35 +0200]:

> CC Alexandre Oliva, who maintains this part of GCC.
> 
> 
> On 4/22/20 11:13 PM, Tom Tromey wrote:
> >>>>>> "Andrew" == Andrew Burgess <andrew.burgess@embecosm.com> writes:
> > 
> > I read through the various threads on this topic, though I think maybe
> > not very well.
> > 
> > IIUC, the issue at hand is that there are two proposed patches to fix
> > various issues in this area.
> > 
> > 
> > Andrew's patch takes us roughly to the status quo from before is-stmt
> > landed.  This patch takes the view that GCC is currently buggy, so one
> > test is partly disabled; and there's a new bug so we can fix GDB once
> > GCC is fixed.
> > 
> > Bernd's patch takes the view that GCC won't be fixed and tries to work
> > around the problem; it drops at least one "FILE:LINE" case that
> > currently works.
> > 
> > 
> > Is that a fair summary?  There were many messages and details, so I'm
> > not sure I either understood it all or that it can be summarized like
> > this.
> > 
> 
> Yes, I agree with this summary.
> 
> > If that's fair, then my inclination is to move forward with Andrew's
> > patch for the time being, with the primary justification being
> > conservatism.  Bernd's patch can always land if/when we have some
> > clarification from GCC about whether the bugs there will be fixed.
> > 
> > Let me know what you think.
> > 
> 
> I think if we take Andrew's patch the only possible outcome
> will be that gcc will disable that statement frontiers debug
> option by default, because they do not understand what we
> want from them.  (I am one of them, but I came here to understand
> you better)

I tried to describe the two current issues I see with GCC in this bug
report[1] but after a stupid mistake by me of using an older version
of binutils the conversation got side-tracked into a discussion about
view numbers and GDB.

It is my position that neither of the bugs described in [1] require
view number changes, nor additional DWARF features, they could be
fixed entirely withing GCC (in theory at least).

I'm not entirely sure which bit of debug statement frontiers is
responsible for.

After reading one of your other email[2], in which you said this bug
was present from GCC-7 I went and ran some tests, as I thought
gdb.cp/step-and-next-inline.exp doesn't run on GCC-7 as GCC that old
doesn't support -gstatement-frontiers.  I was right, that flag doesn't
exist on GCC-7, and your were correct that some of the range bugs (at
least) do still exist on GCC-7.

After reading[2] I'd also be interest to understand what flaw in DWARF
you feel makes a difference in this case.  Given some of your feedback
in [1] I think that you might be talking about improvements (the
addition of?) to the view number support, but while I agree with you
that this might (would?) allow for improved debug experience, I don't
think it would be needed in order for GCC to do better in this case.

I think it is great Bernd, that you are reaching out from the GCC
community to engage with GDB, this is certainly the best way to ensure
that we can work together as communities to give the best possible
debug experience, and I'm sorry you feel that I have not been clear
enough about the issues I'm seeing here.

I do still think that merging my patch is the correct way to move
forward, however, I don't think the future has to be as bleak as you
describe above.  I am happy to continue discussing this issue for as
long as you are in order to try and find a solution that makes
everyone happy.  That said, here's what I think would need to happen
so that _I_ (personally) was happy to accept your patch:

  1. We need to agree what we're working around.  In [2] you describe
  this issue as a flaw in DWARF, while in [1] I describe this as an
  issue in GCC.  I think we need to first need to agree on what the
  spec says, what GCC can (currently) do in an ideal world, and what
  GCC can be expected to do (currently) in the real world.

  2. We should change GDB assuming that any bugs in GCC or DWARF will
  one day be fixed, and that when that happens we would, ideally, not
  have to apply the work around.  So fixes should be guarded with a
  check of either the producer or the DWARF version.

  3. Currently (to me) it appears that we are crafting a work around
  based on one test case (gdb.cp/step-and-next-inline.exp).  My
  concern here is that when we talk about changing the line table, or
  range handling, these are pretty core aspects of GDB.

  As a GCC developer you probably have more insight, but it doesn't
  feel clear to me yet, do we know that GCC always misbehaves in the
  same say across all, or most, compiled code?

  I don't know how we address this without merging your patch,
  releasing GDB and seeing how it works in the wild.  However, if we
  did decide to "just try it", I would still prefer we staged things
  as:
    (a) Merge my patch, targeted regression fix, then
    (b) Your patch, new functionality GCC/DWARF ranges work around.
  In this way, if we end up backing out some or all of (b) we still
  have (a) in place that fixes the regression.  I'm more than happy
  for a rebase of (b) in include full removal of (a).

Thanks for your continued input.

Andrew

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94474
[2] https://sourceware.org/pipermail/gdb-patches/2020-April/167933.html