GDB 8.2 release 2018-08-21 status update

GDB 8.2 release 2018-08-21 status update

[Joel Brobecker]

Hello,

We are now at nearly 7 weeks since we created the 8.1.90 pre-release.
This is a bit longer than the time we typically take to get the first
release out, but considering we're in the middle of the summer with
lots of us taking holidays (including myself), this is a bit to be
expected...

As you will see from below, there is potentially still a fair amount
of work to do :-/.

Here is the currently list of PRs we identified as blocking for 8.2:

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

  * [KevinB] PR symtab/23010
    Regression: Assertion: SYMBOL_LANGUAGE (sym) == DICT_LANGUAGE (dict)->la_language
    https://sourceware.org/bugzilla/show_bug.cgi?id=23010

        This regression was seemingly fixed, and then makes a come back.
        I suggested we double-check this is indeed still a regression.

  * [StanC] PR varobj/23378
    gdb.mi/mi-var-cmd.exp, with gdbserver
    https://sourceware.org/bugzilla/show_bug.cgi?id=23378

        GDB not reporting that a variable is now out of scope
        (when in native GDBserver mode).

The following PRs are currently unassigned; Pedro's name was tentatively
put down, but only because he had the misfortune of being the reporter.
If possible, we should try to help Pedro finding the commit that caused
the regression -- I will take care of bisecting 23374 (a big Thank You
to Sergio DJ for helping with 23378).

  * [*UNASSIGNED* (Joel???)] PR gdb/23374
    gdb.base/execl-update-breakpoints.exp, with --target_board=native-gdbserver
    https://sourceware.org/bugzilla/show_bug.cgi?id=23374

        No problem with native debugging, or when using the native
        gdbserver in extended-remote mode.

  * [*UNASSIGNED* (Pedro???)] PR gdb/23375
    gdb.base/jit-simple.exp, with --target_board=native-gdbserver
    https://sourceware.org/bugzilla/show_bug.cgi?id=23375

        Same as above, native debugging and extended-remote OK.

  * [*UNASSIGNED* (Pedro???)] PR python/23379
    gdb.python/py-evthreads.exp, with gdbserver
    https://sourceware.org/bugzilla/show_bug.cgi?id=23379

        Internal error running to a breakpoint, when in native gdbserver
        mode. Pure native mode is OK.

Thanks!
-- 
Joel

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

[Kevin Buettner]

On Tue, 21 Aug 2018 10:51:36 -0700
Joel Brobecker <brobecker@adacore.com> 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?

I know that the current patches won't apply cleanly - I had to do a
bit of work yesterday to rebase my v2 work to the current sources.
It probably won't be too hard though...

>   * [KevinB] PR symtab/23010
>     Regression: Assertion: SYMBOL_LANGUAGE (sym) == DICT_LANGUAGE (dict)->la_language
>     https://sourceware.org/bugzilla/show_bug.cgi?id=23010
> 
>         This regression was seemingly fixed, and then makes a come back.
>         I suggested we double-check this is indeed still a regression.

I think this one is for Keith? (I've added him to the CC.)

Kevin

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

[Simon Marchi]

On 2018-08-21 13:51, Joel Brobecker wrote:
>   * [*UNASSIGNED* (Pedro???)] PR gdb/23375
>     gdb.base/jit-simple.exp, with --target_board=native-gdbserver
>     https://sourceware.org/bugzilla/show_bug.cgi?id=23375
> 
>         Same as above, native debugging and extended-remote OK.

I'll give a shot at bisecting this one.

Simon

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

[Simon Marchi]

On 2018-08-21 15:02, Simon Marchi wrote:
> On 2018-08-21 13:51, Joel Brobecker wrote:
>>   * [*UNASSIGNED* (Pedro???)] PR gdb/23375
>>     gdb.base/jit-simple.exp, with --target_board=native-gdbserver
>>     https://sourceware.org/bugzilla/show_bug.cgi?id=23375
>> 
>>         Same as above, native debugging and extended-remote OK.
> 
> I'll give a shot at bisecting this one.
> 
> Simon

The failure seems to have been introduced by c12a508 ("Add client_state 
struct.") as well.

Simon

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

[Joel Brobecker]

> The failure seems to have been introduced by c12a508 ("Add
> client_state struct.") as well.

Thanks Simon. That made me want to check this commit for the PR I said
I would check...

  * [*UNASSIGNED* (Joel???)] PR gdb/23374
    gdb.base/execl-update-breakpoints.exp, with --target_board=native-gdbserver
    https://sourceware.org/bugzilla/show_bug.cgi?id=23374

        No problem with native debugging, or when using the native
        gdbserver in extended-remote mode.

... and indeed, it's also caused, somehow, by commit c12a508.

-- 
Joel

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

[Joel Brobecker]

>   * [*UNASSIGNED* (Pedro???)] PR python/23379
>     gdb.python/py-evthreads.exp, with gdbserver
>     https://sourceware.org/bugzilla/show_bug.cgi?id=23379
> 
>         Internal error running to a breakpoint, when in native gdbserver
>         mode. Pure native mode is OK.

Unless someone wants to do the bisecting, I will bisect this one
tomorrow.

-- 
Joel

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

[Simon Marchi]

On 2018-08-21 16:55, Joel Brobecker wrote:
>>   * [*UNASSIGNED* (Pedro???)] PR python/23379
>>     gdb.python/py-evthreads.exp, with gdbserver
>>     https://sourceware.org/bugzilla/show_bug.cgi?id=23379
>> 
>>         Internal error running to a breakpoint, when in native 
>> gdbserver
>>         mode. Pure native mode is OK.
> 
> Unless someone wants to do the bisecting, I will bisect this one
> tomorrow.

This one seems to come from

   00431a7 ("Use thread_info and inferior pointers more throughout")

Simon

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

[Simon Marchi]

On 2018-08-21 16:54, Joel Brobecker wrote:
>> The failure seems to have been introduced by c12a508 ("Add
>> client_state struct.") as well.
> 
> Thanks Simon. That made me want to check this commit for the PR I said
> I would check...
> 
>   * [*UNASSIGNED* (Joel???)] PR gdb/23374
>     gdb.base/execl-update-breakpoints.exp, with 
> --target_board=native-gdbserver
>     https://sourceware.org/bugzilla/show_bug.cgi?id=23374
> 
>         No problem with native debugging, or when using the native
>         gdbserver in extended-remote mode.
> 
> ... and indeed, it's also caused, somehow, by commit c12a508.

It seems like both of these are caused by a small thinko in that commit. 
  I posted a patch here:

https://sourceware.org/ml/gdb-patches/2018-08/msg00537.html

Simon

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

[Simon Marchi]

On 2018-08-22 12:07, Simon Marchi wrote:
> On 2018-08-21 16:54, Joel Brobecker wrote:
>>> The failure seems to have been introduced by c12a508 ("Add
>>> client_state struct.") as well.
>> 
>> Thanks Simon. That made me want to check this commit for the PR I said
>> I would check...
>> 
>>   * [*UNASSIGNED* (Joel???)] PR gdb/23374
>>     gdb.base/execl-update-breakpoints.exp, with 
>> --target_board=native-gdbserver
>>     https://sourceware.org/bugzilla/show_bug.cgi?id=23374
>> 
>>         No problem with native debugging, or when using the native
>>         gdbserver in extended-remote mode.
>> 
>> ... and indeed, it's also caused, somehow, by commit c12a508.
> 
> It seems like both of these are caused by a small thinko in that
> commit.  I posted a patch here:
> 
> https://sourceware.org/ml/gdb-patches/2018-08/msg00537.html
> 
> Simon

You can scratch 23374 and 23375 from that list.

Simon

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

[Stan Cox]

On 08/22/2018 12:07 PM, Simon Marchi wrote:

> It seems like both of these are caused by a small thinko in that commit. 
>   I posted a patch here:

Doh!  Thanks for finding that!

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

[Simon Marchi]

On 2018-08-22 14:03, Stan Cox wrote:
> On 08/22/2018 12:07 PM, Simon Marchi wrote:
> 
>> It seems like both of these are caused by a small thinko in that 
>> commit.   I posted a patch here:
> 
> Doh!  Thanks for finding that!

No problem, you can blame it on the reviewers for not spotting it :P.

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

[Pedro Alves]

On 08/21/2018 10:29 PM, Simon Marchi wrote:
> On 2018-08-21 16:55, Joel Brobecker wrote:
>>>   * [*UNASSIGNED* (Pedro???)] PR python/23379
>>>     gdb.python/py-evthreads.exp, with gdbserver
>>>     https://sourceware.org/bugzilla/show_bug.cgi?id=23379
>>>
>>>         Internal error running to a breakpoint, when in native gdbserver
>>>         mode. Pure native mode is OK.
>>
>> Unless someone wants to do the bisecting, I will bisect this one
>> tomorrow.
> 
> This one seems to come from
> 
>   00431a7 ("Use thread_info and inferior pointers more throughout")
Thanks for bisecting!  I'm taking a look at it.

Thanks,
Pedro Alves

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

[Simon Marchi]

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.

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.

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?

Simon

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

[Kevin Buettner]

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

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

[Kevin Buettner]

On Tue, 21 Aug 2018 10:51:36 -0700
Joel Brobecker <brobecker@adacore.com> 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?

I was able to apply the eight "non-contiguous address range support"
patches to my local checkout of gdb-8.2-branch.  Part #2 needed some
fixing, but everything else applied cleanly (which kind of surprised
me).

I've tested on x86-64.  No regressions.

Let me know if you want it pushed...

Kevin

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

[Pedro Alves]

On 08/23/2018 06:56 PM, Pedro Alves wrote:
> On 08/21/2018 10:29 PM, Simon Marchi wrote:
>> On 2018-08-21 16:55, Joel Brobecker wrote:
>>>>   * [*UNASSIGNED* (Pedro???)] PR python/23379
>>>>     gdb.python/py-evthreads.exp, with gdbserver
>>>>     https://sourceware.org/bugzilla/show_bug.cgi?id=23379
>>>>
>>>>         Internal error running to a breakpoint, when in native gdbserver
>>>>         mode. Pure native mode is OK.
>>>
>>> Unless someone wants to do the bisecting, I will bisect this one
>>> tomorrow.
>>
>> This one seems to come from
>>
>>   00431a7 ("Use thread_info and inferior pointers more throughout")
> Thanks for bisecting!  I'm taking a look at it.

This fixes it:
  https://sourceware.org/ml/gdb-patches/2018-08/msg00595.html

Thanks,
Pedro Alves

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

[Pedro Alves]

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

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

[Simon Marchi]

On 2018-08-24 14:35, Pedro Alves wrote:
> 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.

Seems nobody is against it.  Go!

> Unless I'm wrong that
> -freorder-blocks-and-partition is on by default in GCC 8 already?

Looking at gcc/doc/invoke.texi, apparently it's been enabled for -O2/-O3 
for some time and more recently -Os.  You can check whether it is 
enabled with:

   gcc -Q -v --help 2>/dev/null | grep reorder-blocks-and-partition

I see it as disabled by default and enabled if I add -O2, with different 
gcc versions between 5.4.0 and 8.2.0.  So it doesn't seem to have 
changed recently.  Maybe what changed is that gcc 8 partitions more 
aggressively?  Or it's just that gcc developers tend to debug -O2 
builds?  I have no idea.

Simon

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

[Pedro Alves]

On 08/24/2018 08:14 PM, Simon Marchi wrote:
> On 2018-08-24 14:35, Pedro Alves wrote:

>> Unless I'm wrong that
>> -freorder-blocks-and-partition is on by default in GCC 8 already?
> 
> Looking at gcc/doc/invoke.texi, apparently it's been enabled for -O2/-O3 for some time and more recently -Os.  You can check whether it is enabled with:
> 
>   gcc -Q -v --help 2>/dev/null | grep reorder-blocks-and-partition
> 
> I see it as disabled by default and enabled if I add -O2, with different gcc versions between 5.4.0 and 8.2.0.  So it doesn't seem to have changed recently.  Maybe what changed is that gcc 8 partitions more aggressively?  Or it's just that gcc developers tend to debug -O2 builds?  I have no idea.

Here's what Jakub Jelinek had to say about it:

 <palves> is -freorder-blocks-and-partition on by default in any gcc release yet?
 <jakub_> palves: yes, in gcc 8
 <jakub_> palves: for older releases I believe it has been enabled, but due to a bug actually disabled later on, unless -fprofile-use was used
 <jakub_> palves: "-freorder-blocks-and-partition, a pass splitting function bodies into hot and cold regions, is now enabled by default at -O2 and higher for x86 and x86-64." is in gcc.gnu.org/gcc-8/changes.html
 <jakub_> palves: it was added for -fprofile-use initially, and its test coverage was using usually explicit -freorder-blocks-and-partition

Thanks,
Pedro Alves

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

[Kevin Buettner]

On Thu, 23 Aug 2018 20:57:18 -0700
Kevin Buettner <kevinb@redhat.com> wrote:

> On Tue, 21 Aug 2018 10:51:36 -0700
> Joel Brobecker <brobecker@adacore.com> 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?  
> 
> I was able to apply the eight "non-contiguous address range support"
> patches to my local checkout of gdb-8.2-branch.  Part #2 needed some
> fixing, but everything else applied cleanly (which kind of surprised
> me).
> 
> I've tested on x86-64.  No regressions.
> 
> Let me know if you want it pushed...

Based on comments and discussion from Simon and Pedro elsewhere in
this thread, it seems that it ought to go in, so...

I've pushed the "non-contiguous address range support" patches to
gdb-8.2-branch.

Kevin