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

[Pedro Alves <palves@redhat.com>]

On 08/23/2018 11:41 PM, Kevin Buettner wrote:
> Simon Marchi <simon.marchi@polymtl.ca> wrote:

>> 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?

Yeah, the main issue here is that nowadays -freorder-blocks-and-partition 
is on by default in GCC (I believe the switch was flipped in GCC 8?), which
means users will run into this problem more frequently going forward.  While
technically it's not a GDB regression (you can always run into this if you
build your program with -freorder-blocks-and-partition explicitly), from
the perspective of end users looking at the toolchain as whole black box,
it's a toolchain regression (defaults no longer work).
I'd support putting the series in GDB 8.2.  Unless I'm wrong that
-freorder-blocks-and-partition is on by default in GCC 8 already?

> 
> 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.
While I'm all for helping our GCC hacker friends, I'm more concerned
with the general users, since presumably GCC developers would have no
big trouble building a new GDB from sources.

Thanks,
Pedro Alves