Re: GDB 8.2 release 2018-08-21 status update

[Kevin Buettner <kevinb@redhat.com>]

On Thu, 23 Aug 2018 14:36:54 -0400
Simon Marchi <simon.marchi@polymtl.ca> wrote:

> On 2018-08-21 13:51, Joel Brobecker wrote:
> >   * [KevinB] PR gdb/23021
> >     Setting breakpoints with -freorder-blocks-and-partition
> >     https://sourceware.org/bugzilla/show_bug.cgi?id=23021
> > 
> > 	Identified as needed in the previous release, but couldn't do it
> >         in time. We should be very close, now:
> >         [v3] 
> > https://sourceware.org/ml/gdb-patches/2018-08/msg00467.html
> > 
> >         I'm wondering how reasonable it's going to be to backport
> >         those changes onto the branch, though... Any thoughts on that?
> >         Kevin? Simon?  
> 
> The changeset does indeed look scary :).  But I think Kevin was careful 
> to keep the existing behaviour for contiguous blocks.
> 
> Patches 1 and 2 look harmless.
> 
> Patches 3 and 4 mostly added some branches for the contiguous and the 
> non-contiguous case, where the contiguous case keeps the former 
> behaviour.  If you have an executable with only contiguous blocks, it 
> *should* therefore work the same way as before.  If you have an 
> executable with non-contiguous blocks, well it would be broken with GDB 
> 8.1, so anything is an improvement.
> 
> Patch 5 changes BLOCK_START for BLOCK_ENTRY_PC, which is supposed to be 
> the same for contiguous blocks, so again no changes expected there.
> 
> I'm not sure about the impact of patch 6.

For contiguous blocks, there's no change in behavior for patch 6
either.

I.e. find_function_entry_range_from_pc provides the same answer as
find_pc_partial_function when invoked on a function occupying a
contiguous block.

> 
> Patch 7 modifies the block range data, which is only used in the 
> non-contiguous branches.  So again, no impact on existing 
> contiguous-only executables.

I agree with the rest of your analysis.

> So from my point of view, it would be fine to include it in 8.2.  I'm 
> just wondering though why this was considered as a blocker for 8.2 in 
> the first place.  It's not really a regression, it's more like a new 
> feature.  Was it to make sure we get the feature to users faster, before 
> the new gcc that emits code like this by default starts to spread too 
> much?

According to Thomas Koenig, from GCC bug 84550:

    With gdb 8.0.1, stepping through functions after breakpoints is
    often broken.  This makes it hard to debug gcc itself.

The non-contiguous address ranges patches _might_ make it easier for
gcc developers to debug gcc.

Kevin