GDB 10 branching - 2020-06-27 Update

GDB 10 branching - 2020-06-27 Update

[Joel Brobecker]

Hi everyone,

Great progress last week, as the first section of this report will
indicate! So far, we're down to 3 identified issues we would like
to fix before branching. As always, if you see anything else that
you think should make the list, please let us know!

As a reminder, the proposal was to try to branch during the weekend
of July 4th if we can, which is very soon. From there, we would then
aim for a release 2-3 weeks later.

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

  * [RainerO/PedroA]
    <PR gdb/25939> [10 regression] run fails with ICE on Solaris
    https://sourceware.org/bugzilla/show_bug.cgi?id=25939

  * [AndrewB/TomT]
    QEMU / GDB compatibility on RISCV64 ELF (failure to fetch some registers)
    https://sourceware.org/pipermail/gdb-patches/2020-June/169393.html

    Reference to the patch series that got pushed a couple of days ago:
    https://sourceware.org/pipermail/gdb-patches/2020-June/169561.html
    Subject: RISC-V target description and register handling fixes

  * [PhilippeW]
    <PR gdb/25475>
    https://sourceware.org/bugzilla/show_bug.cgi?id=25475

  * [PhilippeW]
    Allow the user to define default args for aliases
    https://sourceware.org/pipermail/gdb-patches/2020-June/169467.html

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

  * [Unassigned (reported by LuisM)] <PR gdb/26175>
    Regression on testsuite due to changes to default_target_compile
    https://sourceware.org/bugzilla/show_bug.cgi?id=26175

    Patch causes some options to be missing when compiling test code.

  * [AndrewB]
    Fix Python unwinders and inline frames
    https://sourceware.org/pipermail/gdb-patches/2020-June/169789.html

    Difficult issue to solve. Andrew mentioned he would appreciate
    feedback from others who might be familiar with this area
    (inline frames hanlding). Andrew provided in his commit revlog
    a very detailed explanation of the situation.

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

  * [TomT/HannesD]
    <PR win32/25302> Mismatching fstat() function calls in gdb_bfd_open() and cache_bstat()
    https://sourceware.org/bugzilla/show_bug.cgi?id=25302

    Latest discussion at:
    https://sourceware.org/pipermail/gdb-patches/2020-June/169670.html

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

  <none>

-- 
Joel

Re: GDB 10 branching - 2020-06-27 Update

[Rainer Orth]

Hi Joel,

> Great progress last week, as the first section of this report will
> indicate! So far, we're down to 3 identified issues we would like
> to fix before branching. As always, if you see anything else that
> you think should make the list, please let us know!

it would be nice to get

	[PATCH] Unify Solaris procfs and largefile handling
        https://sourceware.org/pipermail/gdb-patches/2020-June/169977.html

into GDB 10 which unbreaks the 32-bit GDB build on Solaris.  Nick
already approved the binutils parts of the patch; the gdb side is pretty
much mechanical.

Thanks.
        Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: GDB 10 branching - 2020-06-27 Update

[Joel Brobecker]

> it would be nice to get
> 
> 	[PATCH] Unify Solaris procfs and largefile handling
>         https://sourceware.org/pipermail/gdb-patches/2020-June/169977.html
> 
> into GDB 10 which unbreaks the 32-bit GDB build on Solaris.  Nick
> already approved the binutils parts of the patch; the gdb side is pretty
> much mechanical.

Sounds good to me, Rainer. Thanks for pointing it out.

-- 
Joel

Re: GDB 10 branching - 2020-06-27 Update

[Simon Marchi]

On 2020-06-27 11:40 a.m., Joel Brobecker wrote:
> Hi everyone,
> 
> Great progress last week, as the first section of this report will
> indicate! So far, we're down to 3 identified issues we would like
> to fix before branching. As always, if you see anything else that
> you think should make the list, please let us know!
> 
> As a reminder, the proposal was to try to branch during the weekend
> of July 4th if we can, which is very soon. From there, we would then
> aim for a release 2-3 weeks later.
> 
> Fixed Since the Previous Update:
> --------------------------------
> 
>   * [RainerO/PedroA]
>     <PR gdb/25939> [10 regression] run fails with ICE on Solaris
>     https://sourceware.org/bugzilla/show_bug.cgi?id=25939
> 
>   * [AndrewB/TomT]
>     QEMU / GDB compatibility on RISCV64 ELF (failure to fetch some registers)
>     https://sourceware.org/pipermail/gdb-patches/2020-June/169393.html
> 
>     Reference to the patch series that got pushed a couple of days ago:
>     https://sourceware.org/pipermail/gdb-patches/2020-June/169561.html
>     Subject: RISC-V target description and register handling fixes
> 
>   * [PhilippeW]
>     <PR gdb/25475>
>     https://sourceware.org/bugzilla/show_bug.cgi?id=25475
> 
>   * [PhilippeW]
>     Allow the user to define default args for aliases
>     https://sourceware.org/pipermail/gdb-patches/2020-June/169467.html
> 
> Added Since the Last Update:
> ----------------------------
> 
>   * [Unassigned (reported by LuisM)] <PR gdb/26175>
>     Regression on testsuite due to changes to default_target_compile
>     https://sourceware.org/bugzilla/show_bug.cgi?id=26175
> 
>     Patch causes some options to be missing when compiling test code.
> 
>   * [AndrewB]
>     Fix Python unwinders and inline frames
>     https://sourceware.org/pipermail/gdb-patches/2020-June/169789.html
> 
>     Difficult issue to solve. Andrew mentioned he would appreciate
>     feedback from others who might be familiar with this area
>     (inline frames hanlding). Andrew provided in his commit revlog
>     a very detailed explanation of the situation.
> 
> Other Ongoing Items:
> --------------------
> 
>   * [TomT/HannesD]
>     <PR win32/25302> Mismatching fstat() function calls in gdb_bfd_open() and cache_bstat()
>     https://sourceware.org/bugzilla/show_bug.cgi?id=25302
> 
>     Latest discussion at:
>     https://sourceware.org/pipermail/gdb-patches/2020-June/169670.html
> 
> Not Critical, but Requested:
> ----------------------------
> 
>   <none>
> 
> -- 
> Joel
> 

Hi Joel,

I stumbled on a bug introduced by the multi-target patch, which I think should be a
blocker for the release (not necessarily the branching).  I marked it with target
milestone 10.1 in bugzilla:

https://sourceware.org/bugzilla/show_bug.cgi?id=26199

Simon

Re: GDB 10 branching - 2020-06-27 Update

[Simon Marchi]

On 2020-06-27 11:40 a.m., Joel Brobecker wrote:
> Hi everyone,
> 
> Great progress last week, as the first section of this report will
> indicate! So far, we're down to 3 identified issues we would like
> to fix before branching. As always, if you see anything else that
> you think should make the list, please let us know!
> 
> As a reminder, the proposal was to try to branch during the weekend
> of July 4th if we can, which is very soon. From there, we would then
> aim for a release 2-3 weeks later.
> 
> Fixed Since the Previous Update:
> --------------------------------
> 
>   * [RainerO/PedroA]
>     <PR gdb/25939> [10 regression] run fails with ICE on Solaris
>     https://sourceware.org/bugzilla/show_bug.cgi?id=25939
> 
>   * [AndrewB/TomT]
>     QEMU / GDB compatibility on RISCV64 ELF (failure to fetch some registers)
>     https://sourceware.org/pipermail/gdb-patches/2020-June/169393.html
> 
>     Reference to the patch series that got pushed a couple of days ago:
>     https://sourceware.org/pipermail/gdb-patches/2020-June/169561.html
>     Subject: RISC-V target description and register handling fixes
> 
>   * [PhilippeW]
>     <PR gdb/25475>
>     https://sourceware.org/bugzilla/show_bug.cgi?id=25475
> 
>   * [PhilippeW]
>     Allow the user to define default args for aliases
>     https://sourceware.org/pipermail/gdb-patches/2020-June/169467.html
> 
> Added Since the Last Update:
> ----------------------------
> 
>   * [Unassigned (reported by LuisM)] <PR gdb/26175>
>     Regression on testsuite due to changes to default_target_compile
>     https://sourceware.org/bugzilla/show_bug.cgi?id=26175
> 
>     Patch causes some options to be missing when compiling test code.
> 
>   * [AndrewB]
>     Fix Python unwinders and inline frames
>     https://sourceware.org/pipermail/gdb-patches/2020-June/169789.html
> 
>     Difficult issue to solve. Andrew mentioned he would appreciate
>     feedback from others who might be familiar with this area
>     (inline frames hanlding). Andrew provided in his commit revlog
>     a very detailed explanation of the situation.
> 
> Other Ongoing Items:
> --------------------
> 
>   * [TomT/HannesD]
>     <PR win32/25302> Mismatching fstat() function calls in gdb_bfd_open() and cache_bstat()
>     https://sourceware.org/bugzilla/show_bug.cgi?id=25302
> 
>     Latest discussion at:
>     https://sourceware.org/pipermail/gdb-patches/2020-June/169670.html
> 
> Not Critical, but Requested:
> ----------------------------
> 
>   <none>
> 
> -- 
> Joel
> 

Another item would be the Guile 2.2 and 3.0 support, the latest version
being here:

  https://sourceware.org/pipermail/gdb-patches/2020-June/169936.html

It's been a quite long-running issue:

  https://sourceware.org/bugzilla/show_bug.cgi?id=21104

and it's nice to finally have someone address it.  It would be a shame
I think if it didn't make it into this release.

I have looked at the patches, but I know nothing about this, so I can't
review them properly.  Do you know who would be most qualified to review
this?

Simon

Re: GDB 10 branching - 2020-06-27 Update

[Eli Zaretskii]

> From: Simon Marchi <simark@simark.ca>
> Date: Thu, 2 Jul 2020 20:35:11 -0400
> Cc: Tom Tromey <tom@tromey.com>
> 
>   https://sourceware.org/pipermail/gdb-patches/2020-June/169936.html
> 
> It's been a quite long-running issue:
> 
>   https://sourceware.org/bugzilla/show_bug.cgi?id=21104
> 
> and it's nice to finally have someone address it.  It would be a shame
> I think if it didn't make it into this release.

I agree.

> I have looked at the patches, but I know nothing about this, so I can't
> review them properly.  Do you know who would be most qualified to review
> this?

I thought Doug would chime in, but he didn't.

Re: GDB 10 branching - 2020-06-27 Update

[Sebastian Huber]

Hello,

On 27/06/2020 17:40, Joel Brobecker wrote:
> Not Critical, but Requested:
> ----------------------------
>
>    <none>

it would be nice to have a fix for linker errors with GCC 10 
(-fno-common default):

https://sourceware.org/pipermail/gdb-patches/2020-July/170083.html

https://sourceware.org/pipermail/gdb-patches/2020-July/170084.html

I built GDB for the following targets recently with GCC 10:

* aarch64-rtems
* arm-rtems
* bfin-rtems
* i386-rtems
* lm32-rtems
* m68k-rtems
* microblaze-rtems
* mips-rtems
* moxie-rtems
* nios2-rtems
* or1k-rtems
* powerpc-rtems
* riscv-rtems
* sh-rtems
* sparc-rtems
* sparc64-rtems
* v850-rtems
* x86_64-rtems

Only powerpc-rtems and v850-rtems had these linker issues with -fno-common.

Re: GDB 10 branching - 2020-06-27 Update

[Andrew Burgess]

* Sebastian Huber <sebastian.huber@embedded-brains.de> [2020-07-03 10:15:51 +0200]:

> Hello,
> 
> On 27/06/2020 17:40, Joel Brobecker wrote:
> > Not Critical, but Requested:
> > ----------------------------
> > 
> >    <none>
> 
> it would be nice to have a fix for linker errors with GCC 10 (-fno-common
> default):
> 
> https://sourceware.org/pipermail/gdb-patches/2020-July/170083.html
> 
> https://sourceware.org/pipermail/gdb-patches/2020-July/170084.html

I'll try to get these reviewed today or over the weekend.

Thanks,
Andrew


> 
> I built GDB for the following targets recently with GCC 10:
> 
> * aarch64-rtems
> * arm-rtems
> * bfin-rtems
> * i386-rtems
> * lm32-rtems
> * m68k-rtems
> * microblaze-rtems
> * mips-rtems
> * moxie-rtems
> * nios2-rtems
> * or1k-rtems
> * powerpc-rtems
> * riscv-rtems
> * sh-rtems
> * sparc-rtems
> * sparc64-rtems
> * v850-rtems
> * x86_64-rtems
> 
> Only powerpc-rtems and v850-rtems had these linker issues with -fno-common.
> 

Re: GDB 10 branching - 2020-06-27 Update

[Joel Brobecker]

> Another item would be the Guile 2.2 and 3.0 support, the latest version
> being here:
> 
>   https://sourceware.org/pipermail/gdb-patches/2020-June/169936.html
> 
> It's been a quite long-running issue:
> 
>   https://sourceware.org/bugzilla/show_bug.cgi?id=21104
> 
> and it's nice to finally have someone address it.  It would be a shame
> I think if it didn't make it into this release.

I'll follow the group on that one. It's a risk vs reward situation:
How risky is it for us to put the patch in just before the branch,
versus how much do we expect to gain by having it now rather than
in 6 months?  Given that this should only affect Guile support,
I suppose the risk we are taking is limited to that part. If the risk
is low and acceptable to everyone, then we can decide to have it
in GDB 10. I'll put it on the list for now...

> I have looked at the patches, but I know nothing about this, so I can't
> review them properly.  Do you know who would be most qualified to review
> this?

Traditionally, it's been Doug Evans.

-- 
Joel

Re: GDB 10 branching - 2020-06-27 Update

[Joel Brobecker]

> > it would be nice to have a fix for linker errors with GCC 10 (-fno-common
> > default):
> > 
> > https://sourceware.org/pipermail/gdb-patches/2020-July/170083.html
> > 
> > https://sourceware.org/pipermail/gdb-patches/2020-July/170084.html

Agreed.

> I'll try to get these reviewed today or over the weekend.

Thanks Andrew!

-- 
Joel

Re: GDB 10 branching - 2020-06-27 Update

[Joel Brobecker]

> I stumbled on a bug introduced by the multi-target patch, which I
> think should be a blocker for the release (not necessarily the
> branching).  I marked it with target milestone 10.1 in bugzilla:
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=26199

Thanks Simon. Will you be the one actually looking into the problem?
I would understand if not (for whatever reason); knowing it would then
allow us to start searching for someone who could look into it.

-- 
Joel

Re: GDB 10 branching - 2020-06-27 Update

[Simon Marchi]

On 2020-07-03 11:10 a.m., Joel Brobecker wrote:
>> I stumbled on a bug introduced by the multi-target patch, which I
>> think should be a blocker for the release (not necessarily the
>> branching).  I marked it with target milestone 10.1 in bugzilla:
>>
>> https://sourceware.org/bugzilla/show_bug.cgi?id=26199
> 
> Thanks Simon. Will you be the one actually looking into the problem?
> I would understand if not (for whatever reason); knowing it would then
> allow us to start searching for someone who could look into it.

I notified Pedro about it, he and/or I will look into it.

Simon

Re: GDB 10 branching - 2020-06-27 Update

[Simon Marchi]

On 2020-07-03 11:06 a.m., Joel Brobecker wrote:
> I'll follow the group on that one. It's a risk vs reward situation:
> How risky is it for us to put the patch in just before the branch,
> versus how much do we expect to gain by having it now rather than
> in 6 months?  Given that this should only affect Guile support,
> I suppose the risk we are taking is limited to that part. If the risk
> is low and acceptable to everyone, then we can decide to have it
> in GDB 10. I'll put it on the list for now...

The patch is mostly adding new code guarded by #ifdefs based on the
Guile version.  So I think we can check and be reasonably confident
that the code effectively used when building against guile 2.0 won't
have changed much.  All the new code will be compiled out when
building against guile 2.0.  There may be bugs in the support for
guile 2.2/3.0 code, but that's a new feature, so it's better than
no support at all.

Simon

Re: GDB 10 branching - 2020-06-27 Update

[Pedro Alves]

On 7/3/20 4:12 PM, Simon Marchi wrote:
> On 2020-07-03 11:10 a.m., Joel Brobecker wrote:
>>> I stumbled on a bug introduced by the multi-target patch, which I
>>> think should be a blocker for the release (not necessarily the
>>> branching).  I marked it with target milestone 10.1 in bugzilla:
>>>
>>> https://sourceware.org/bugzilla/show_bug.cgi?id=26199
>>
>> Thanks Simon. Will you be the one actually looking into the problem?
>> I would understand if not (for whatever reason); knowing it would then
>> allow us to start searching for someone who could look into it.
> 
> I notified Pedro about it, he and/or I will look into it.

This one's now fixed.