Re: [PATCH v5] Fix range end handling of inlined subroutines

[Simon Marchi via Gdb-patches <gdb-patches@sourceware.org>]

> From 3c345ab5f7c497151d21945cba8668e91db00e7b Mon Sep 17 00:00:00 2001
> From: Bernd Edlinger <bernd.edlinger@hotmail.de>
> Date: Tue, 3 Nov 2020 18:41:43 +0100
> Subject: [PATCH] Fix range end handling of inlined subroutines
> 
> This introduces a new line table flag is_weak.
> The line entries at the end of a subroutine range,
> use this to indicate that they may possibly
> be part of the previous subroutine.
> 
> When there is a sequence of line entries at the
> same address where an inline range ends, and the
> last item has is_stmt = 0, we force all previous
> items to have is_weak = 1.
> 
> This is about the best we can do at the moment,
> unless location view information are added to the
> block ranges debug info structure, and location
> views are implemented in gdb in general.

Ok, I'm not sure I can reasonably review this.

First, it would make the patch easier and more inviting to review if
the commit message went a bit more in depth.  If I know nothing about
the problem, it's some time-consuming patchwork to go read all the
pieces of informations in the bug reports, maybe the test cases, to
try to just understand what is the problem this patch is tackling.

When fixing anything remotely complicated, the commit message should be
of the general form:

- When we do ..., this happens
- This is wrong, we would expect ...
- This is caused by ...
- To avoid this, I propose ...

After reading the commit message, I should at least be convinced that
there is indeed a problem to be fixed and that this patch, in this form
or another, is desirable.

Anyhow, I understand somewhat the problem now (at least the one described
in bug 25987).  But the patch is changing bits of twisted code here and
there without much explanation, and I can't make a mental model of what
each bit does.

Is it possible to split the patch into smaller pieces?  For example, a first
patch could just the DWARF reader, and perhaps other pieces, with the goal
of having no functional changes (just augment GDB's internal line table),
with an explanation of what's added.  With this kind of code, the smaller
the increment the better.

Simon