GDB 11 branching update (2021-05-30)

GDB 11 branching update (2021-05-30)

[Joel Brobecker]

Hello everyone,

Below is an update of the issues we have decided to work on before
we branch. As we can see, there are still quite a few issues left.
There's been progress though, and I'm hoping one or two of them
are just about to be fixed. If at all possible, it would be nice
if we (Global and Area maintainers) could give the issues below
an extra push -- otherwise, I fear that the current development pace
will continue to introduce more issues we want to fix, which will force
us to make a decision between branching with known problems, or going
through a stabilization phase...

Thanks!

Fixed Since the Previous Update:
--------------------------------

  * [MikeF] using gnulib in sim (patches pending)

Added Since the Last Update:
----------------------------

  * [Simon] <PR gdb/27899>
    [GNU/Linux, sparc64] GDB crashes when debugging multithreaded programs
    https://sourceware.org/bugzilla/show_bug.cgi?id=27899

    Simon has a patch that seems to work (posted in bugzill only
    for now).

Other Ongoing Items:
--------------------

  * [TomDV] <PR symtab/26327>
    GDB hangs in get_builder() due to recursive ancestor pointers
    https://sourceware.org/bugzilla/show_bug.cgi?id=26327

    There was a patch, but it caused some regressions, and thus
    it has been reverted, making us reopen this PR.

    One comment in the PR says:
    | The problem is not that we search ancestors, the problem is that
    | we allow ancestors to form a loop.  See detailed investigation at
    | <URL: https://bugzilla.opensuse.org/show_bug.cgi?id=1185800 >.  Your
    | fix looks more like a band-aid to me.

  * [Sergey with Simon as reviewer] <PR tdep/26633>
    Add Z80 CPU support
    https://sourceware.org/bugzilla/show_bug.cgi?id=26633

    Patch submitted at:
    https://sourceware.org/pipermail/gdb-patches/2020-September/172083.html

    High-level pre-review done at:
    https://sourceware.org/pipermail/gdb-patches/2021-May/179191.html

  * [AndrewB/Simon] <PR gdb/26819>
    Bug 26819 - RISC-V: internal-error: int finish_step_over(execution_control_state*): Assertion
    https://sourceware.org/bugzilla/show_bug.cgi?id=26819

    I think the situation has been improved thanks to a couple of
    patches, but the user still has some scenarios where the issue
    happens.

  * [Simon] <PR gdb/26868>
    Follow-up on x86-64 stub submission
    https://sourceware.org/bugzilla/show_bug.cgi?id=26868

    This is the submission in question:
    https://sourceware.org/pipermail/gdb-patches/2020-November/173182.html

    For me, although I am not a lawyer, I don't think we can accept
    the contribution without the author signing a copyright assignment
    form.

  * [Simon/Kevin] <PR gdb/27526>
    Attaching to threaded process on glibc 2.33: libthread_db fails to initialize with "generic error"
    https://sourceware.org/bugzilla/show_bug.cgi?id=27526

    Patch v2 at:
    https://sourceware.org/pipermail/gdb-patches/2021-May/178485.html

  * [SimonM] <PR python/27841>
    Failed assertion: assigning convenience variable during inferior exit Python event
    https://sourceware.org/bugzilla/show_bug.cgi?id=27841

    v3 approved, and copyright assignment received, so about to push.

  * [RainerO] <PR binutils/27666>
    ar doesn't create indices on Solaris/sparcv9
    https://sourceware.org/bugzilla/show_bug.cgi?id=27666

    Causes large number of tests to fail in gdb's testsuite.

    Patch has been proposed by NickC, to be tested by RainerO
    (uploaded to bugzilla). Worse case scenario, we can branch
    and then revert the binutils patch that caused the issue.

  * [LuisM] <PR corefiles/27909>
    AArch64 MTE fixes and corefile support
    https://sourceware.org/bugzilla/show_bug.cgi?id=27909

Not Critical, but Requested:
----------------------------

  < none :) >

Thank you!
-- 
Joel

Re: GDB 11 branching update (2021-05-30)

[John Baldwin]

On 5/30/21 7:24 AM, Joel Brobecker wrote:
> Hello everyone,
> 
> Below is an update of the issues we have decided to work on before
> we branch. As we can see, there are still quite a few issues left.
> There's been progress though, and I'm hoping one or two of them
> are just about to be fixed. If at all possible, it would be nice
> if we (Global and Area maintainers) could give the issues below
> an extra push -- otherwise, I fear that the current development pace
> will continue to introduce more issues we want to fix, which will force
> us to make a decision between branching with known problems, or going
> through a stabilization phase...

I haven't yet filed a PR or sent a patch, but I ran into a breakage
of fork events for child processes on non-Linux platforms (well,
platforms that don't support displaced stepping which is only
supported on Linux currently).  I will post a patch for that later
today.  I will also work on running a comparison of the testsuite
for GDB 10.2 vs current master this week on FreeBSD to see if that
finds any other regressions.

-- 
John Baldwin

Re: GDB 11 branching update (2021-05-30)

[John Baldwin]

On 5/31/21 8:53 AM, John Baldwin wrote:
> On 5/30/21 7:24 AM, Joel Brobecker wrote:
>> Hello everyone,
>>
>> Below is an update of the issues we have decided to work on before
>> we branch. As we can see, there are still quite a few issues left.
>> There's been progress though, and I'm hoping one or two of them
>> are just about to be fixed. If at all possible, it would be nice
>> if we (Global and Area maintainers) could give the issues below
>> an extra push -- otherwise, I fear that the current development pace
>> will continue to introduce more issues we want to fix, which will force
>> us to make a decision between branching with known problems, or going
>> through a stabilization phase...
> 
> I haven't yet filed a PR or sent a patch, but I ran into a breakage
> of fork events for child processes on non-Linux platforms (well,
> platforms that don't support displaced stepping which is only
> supported on Linux currently).  I will post a patch for that later
> today.  I will also work on running a comparison of the testsuite
> for GDB 10.2 vs current master this week on FreeBSD to see if that
> finds any other regressions.

FWIW, the fork events fix was merged.

-- 
John Baldwin

Re: GDB 11 branching update (2021-05-30)

[Joel Brobecker]

> > I haven't yet filed a PR or sent a patch, but I ran into a breakage
> > of fork events for child processes on non-Linux platforms (well,
> > platforms that don't support displaced stepping which is only
> > supported on Linux currently).  I will post a patch for that later
> > today.  I will also work on running a comparison of the testsuite
> > for GDB 10.2 vs current master this week on FreeBSD to see if that
> > finds any other regressions.
> 
> FWIW, the fork events fix was merged.

Awesome news. Thanks for having let me know, John.

-- 
Joel

Re: GDB 11 branching update (2021-05-30)

[Andrew Burgess]

* Joel Brobecker <brobecker@adacore.com> [2021-05-30 07:24:08 -0700]:

>   * [AndrewB/Simon] <PR gdb/26819>
>     Bug 26819 - RISC-V: internal-error: int finish_step_over(execution_control_state*): Assertion
>     https://sourceware.org/bugzilla/show_bug.cgi?id=26819
> 
>     I think the situation has been improved thanks to a couple of
>     patches, but the user still has some scenarios where the issue
>     happens.

I've reviewed the latest reports from the user, and posted some
comments to the bug report.

In summary I think the issues the user was seeing were due to openocd
being miss-configured.  There probably is something we could fix in
GDB so that we give an error rather than triggering an assertion, but
I don't think this should be a blocker for the release.

I would of course, welcome people to review my analysis, and provide
additional insight.

Thanks,
Andrew

Re: GDB 11 branching update (2021-05-30)

[Joel Brobecker]

Hi Andrew,

> >   * [AndrewB/Simon] <PR gdb/26819>
> >     Bug 26819 - RISC-V: internal-error: int finish_step_over(execution_control_state*): Assertion
> >     https://sourceware.org/bugzilla/show_bug.cgi?id=26819
> > 
> >     I think the situation has been improved thanks to a couple of
> >     patches, but the user still has some scenarios where the issue
> >     happens.
> 
> I've reviewed the latest reports from the user, and posted some
> comments to the bug report.
> 
> In summary I think the issues the user was seeing were due to openocd
> being miss-configured.  There probably is something we could fix in
> GDB so that we give an error rather than triggering an assertion, but
> I don't think this should be a blocker for the release.
> 
> I would of course, welcome people to review my analysis, and provide
> additional insight.

Thanks a lot for your help on that one.

-- 
Joel

Re: GDB 11 branching update (2021-05-30)

[Kevin Buettner]

On Sun, 30 May 2021 07:24:08 -0700
Joel Brobecker <brobecker@adacore.com> wrote:

>   * [Simon/Kevin] <PR gdb/27526>
>     Attaching to threaded process on glibc 2.33: libthread_db fails to initialize with "generic error"
>     https://sourceware.org/bugzilla/show_bug.cgi?id=27526
> 
>     Patch v2 at:
>     https://sourceware.org/pipermail/gdb-patches/2021-May/178485.html

I've looked at and commented on Simon's v2 patch.  I found it okay and
think that it should go in.

Kevin

Re: GDB 11 branching update (2021-05-30)

[Florian Weimer]

* Kevin Buettner via Gdb-patches:

> On Sun, 30 May 2021 07:24:08 -0700
> Joel Brobecker <brobecker@adacore.com> wrote:
>
>>   * [Simon/Kevin] <PR gdb/27526>
>>     Attaching to threaded process on glibc 2.33: libthread_db fails to initialize with "generic error"
>>     https://sourceware.org/bugzilla/show_bug.cgi?id=27526
>> 
>>     Patch v2 at:
>>     https://sourceware.org/pipermail/gdb-patches/2021-May/178485.html
>
> I've looked at and commented on Simon's v2 patch.  I found it okay and
> think that it should go in.

Good news.  Cc:ing Simon in case he doesn't follow this thread under a
completely different subject. 8-)

Do we need additional changes on the GDB side for glibc 2.34
compatibility?

How backportable is this patch?  It would help me if it were available
in Fedora 34 and possibly 33.

Thanks,
Florian

Re: GDB 11 branching update (2021-05-30)

[Simon Marchi]

On 2021-06-08 4:40 a.m., Florian Weimer wrote:
> * Kevin Buettner via Gdb-patches:
> 
>> On Sun, 30 May 2021 07:24:08 -0700
>> Joel Brobecker <brobecker@adacore.com> wrote:
>>
>>>   * [Simon/Kevin] <PR gdb/27526>
>>>     Attaching to threaded process on glibc 2.33: libthread_db fails to initialize with "generic error"
>>>     https://sourceware.org/bugzilla/show_bug.cgi?id=27526
>>>
>>>     Patch v2 at:
>>>     https://sourceware.org/pipermail/gdb-patches/2021-May/178485.html
>>
>> I've looked at and commented on Simon's v2 patch.  I found it okay and
>> think that it should go in.
> 
> Good news.  Cc:ing Simon in case he doesn't follow this thread under a
> completely different subject. 8-)

I'll give it another good round of testing and merge it if it's all
clean.

> Do we need additional changes on the GDB side for glibc 2.34
> compatibility?

I think we will.  From what I understood, the interesting symbols will
now be part of libc.so.  We currently gate the loading of
libthread_db.so behind either:

1) a library named libpthread* getting loaded
2) the "main" objfile getting loaded (to support pthread being linked
   statically)

Since we can't assume which library will contain the symbols
libthread_db needs, I don't see any other way than trying to load it at
each library load.  The check for a library named libpthread* was added
because trying to load libthread_db for each library was wasteful for
programs with lots of libraries:

    https://sourceware.org/legacy-ml/gdb-patches/2011-10/msg00144.html

So I guess that will make the situation bad again for these programs.

> How backportable is this patch?  It would help me if it were available
> in Fedora 34 and possibly 33.

I think my patch will be easily backportable, I think it doesn't touch
anything that was changed too recently.  But I haven't tried.

Simon

Re: GDB 11 branching update (2021-05-30)

[Simon Marchi]

On 2021-06-08 1:04 p.m., Simon Marchi via Gdb-patches wrote:
> On 2021-06-08 4:40 a.m., Florian Weimer wrote:
>> * Kevin Buettner via Gdb-patches:
>>
>>> On Sun, 30 May 2021 07:24:08 -0700
>>> Joel Brobecker <brobecker@adacore.com> wrote:
>>>
>>>>   * [Simon/Kevin] <PR gdb/27526>
>>>>     Attaching to threaded process on glibc 2.33: libthread_db fails to initialize with "generic error"
>>>>     https://sourceware.org/bugzilla/show_bug.cgi?id=27526
>>>>
>>>>     Patch v2 at:
>>>>     https://sourceware.org/pipermail/gdb-patches/2021-May/178485.html
>>>
>>> I've looked at and commented on Simon's v2 patch.  I found it okay and
>>> think that it should go in.
>>
>> Good news.  Cc:ing Simon in case he doesn't follow this thread under a
>> completely different subject. 8-)
> 
> I'll give it another good round of testing and merge it if it's all
> clean.

Ok, I pushed the patch.

>> Do we need additional changes on the GDB side for glibc 2.34
>> compatibility?
> 
> I think we will.  From what I understood, the interesting symbols will
> now be part of libc.so.  We currently gate the loading of
> libthread_db.so behind either:
> 
> 1) a library named libpthread* getting loaded
> 2) the "main" objfile getting loaded (to support pthread being linked
>    statically)
> 
> Since we can't assume which library will contain the symbols
> libthread_db needs, I don't see any other way than trying to load it at
> each library load.  The check for a library named libpthread* was added
> because trying to load libthread_db for each library was wasteful for
> programs with lots of libraries:
> 
>     https://sourceware.org/legacy-ml/gdb-patches/2011-10/msg00144.html
> 
> So I guess that will make the situation bad again for these programs.

Let's say I build glibc from git, can you give pointers on how to build
and debug programs against that custom glibc, so I can see how GDB
behaves with the upcoming glibc?

Simon

Re: GDB 11 branching update (2021-05-30)

[Florian Weimer]

* Simon Marchi:

> Let's say I build glibc from git, can you give pointers on how to build
> and debug programs against that custom glibc, so I can see how GDB
> behaves with the upcoming glibc?

“ssh simark@gdbtest.enyo.de” should give you a login on a system with
glibc 2.34 snapshot. (Same SSH key as for sourceware/gcc.gnu.org.)  Let
me know if this is useful.

Alternatively, <https://sourceware.org/glibc/wiki/Testing/Builds> has
instructions how to link to a non-installed glibc (don't forget to
configure with --prefix=/usr), specifically

  <https://sourceware.org/glibc/wiki/Testing/Builds#Compile_against_glibc_build_tree>

But it's unclear how realistic this when it comes to GDB
development/testing.

Kevin, I couldn't find your SSH key, otherwise I'd given you access to
that test system as well.

Thanks,
Florian

Re: GDB 11 branching update (2021-05-30)

[Simon Marchi]

On 2021-06-09 2:37 a.m., Florian Weimer wrote:
> “ssh simark@gdbtest.enyo.de” should give you a login on a system with
> glibc 2.34 snapshot. (Same SSH key as for sourceware/gcc.gnu.org.)  Let
> me know if this is useful.

Thanks!  It is useful, but Kevin already solved it all :).  It could be
useful in the future if we need to test again against some upcoming
glibc.  I checked the Builds glibc wiki page, and there's some scary
stuff in there ;).  I would expect to lose a lot of time trying to make
this work, so I'd rather use a pre-configured system.

I don't know how easy it would be for you, but another option would be
to provide some VM or Docker images.

Simon

Re: GDB 11 branching update (2021-05-30)

[Florian Weimer]

* Simon Marchi:

> On 2021-06-09 2:37 a.m., Florian Weimer wrote:
>> “ssh simark@gdbtest.enyo.de” should give you a login on a system with
>> glibc 2.34 snapshot. (Same SSH key as for sourceware/gcc.gnu.org.)  Let
>> me know if this is useful.
>
> Thanks!  It is useful, but Kevin already solved it all :).  It could be
> useful in the future if we need to test again against some upcoming
> glibc.  I checked the Builds glibc wiki page, and there's some scary
> stuff in there ;).  I would expect to lose a lot of time trying to make
> this work, so I'd rather use a pre-configured system.
>
> I don't know how easy it would be for you, but another option would be
> to provide some VM or Docker images.

The new glibc has been merged into Fedora rawhide, so this container
image

  registry.fedoraproject.org/fedora:rawhide

should help with testing (if you can get GDB to run into a container
etc.).  Fedora also publishes QCOW2 images, I believe.  I can find out
where if those would be useful to you.

Consequently, I've retired the gdbtest machine.

Thanks,
Florian