GDB 8.1.90 available for testing

GDB 8.1.90 available for testing

[Joel Brobecker]

Hello,

I have just finished creating the gdb-8.1.90 pre-release.
It is available for download at the following location:

    ftp://sourceware.org/pub/gdb/snapshots/branch/gdb-8.1.90.tar.xz

A gzip'ed version is also available: gdb-8.1.90.tar.gz.

Please give it a test if you can and report any problems you might find.

On behalf of all the GDB contributors, thank you!
-- 
Joel Brobecker

Re: GDB 8.1.90 available for testing

[Eli Zaretskii]

> From: Joel Brobecker <brobecker@adacore.com>
> Date: Wed,  4 Jul 2018 09:22:02 -0700 (PDT)
> 
> I have just finished creating the gdb-8.1.90 pre-release.
> It is available for download at the following location:
> 
>     ftp://sourceware.org/pub/gdb/snapshots/branch/gdb-8.1.90.tar.xz
> 
> A gzip'ed version is also available: gdb-8.1.90.tar.gz.
> 
> Please give it a test if you can and report any problems you might find.

I've built this with mingw.org's MinGW.  I found one problem in
libiberty (which I will report separately), and I saw 3 warnings while
compiling GDB sources:

       CXX    infrun.o
     In file included from infrun.c:26:0:
     inferior.h: In function 'void handle_vfork_child_exec_or_exit(int)':
     inferior.h:533:39: warning: '*((void*)(& maybe_restore_inferior)+20).scoped_restore_current_inferior::m_saved_inf' may be used uninitialized in this function [-Wmaybe-uninitialized]
	{ set_current_inferior (m_saved_inf); }
					    ^
     infrun.c:929:6: note: '*((void*)(& maybe_restore_inferior)+20).scoped_restore_current_inferior::m_saved_inf' was declared here
	   maybe_restore_inferior;
	   ^~~~~~~~~~~~~~~~~~~~~~
     In file included from inferior.h:49:0,
		      from infrun.c:26:
     progspace.h:285:47: warning: '*((void*)(& maybe_restore_inferior)+16).scoped_restore_current_program_space::m_saved_pspace' may be used uninitialized in this function [-Wmaybe-uninitialized]
	{ set_current_program_space (m_saved_pspace); }
						    ^
     infrun.c:929:6: note: '*((void*)(& maybe_restore_inferior)+16).scoped_restore_current_program_space::m_saved_pspace' was declared here
	   maybe_restore_inferior;
	   ^~~~~~~~~~~~~~~~~~~~~~

   Same warnings were in GDB 8.1; ignored.

       CXX    symfile.o
     symfile.c: In function 'void set_objfile_default_section_offset(objfile*, const section_addr_info&, CORE_ADDR)':
     symfile.c:2114:14: warning: types may not be defined in a for-range-declaration
	for (const struct other_sections *objf_sect : objf_addrs_sorted)
		   ^~~~~~

The first two I saw in GDB 8.1 and reported back in January.  I
believe the conclusion was that we disregard these warnings?

But what about the 3rd one?

Other that that, the build went cleanly.  The new GDB binary, when
invoked on itself, reports the following DWARF-related issues:

     During symbol reading, unsupported tag: 'DW_TAG_unspecified_type'.
     During symbol reading, Member function "~_Sp_counted_base" (offset 0x3ef4f6) is virtual but the vtable offset is not specified.
     During symbol reading, cannot get low and high bounds for subprogram DIE at 0x409823.
     During symbol reading, cannot get low and high bounds for subprogram DIE at 0x409adc.
     During symbol reading, Member function "~probe" (offset 0x435e1c) is virtual but the vtable offset is not specified.
     During symbol reading, Child DIE 0x44114f and its abstract origin 0x446b8b have different parents.
     During symbol reading, Child DIE 0x4411cb and its abstract origin 0x446b8b have different parents.
     During symbol reading, No DW_FORM_block* DW_AT_call_value for DW_TAG_call_site child DIE 0x444e5c [in module d:\usr\eli\utils\gdb-8.1.90\gdb\gdb.exe].
     During symbol reading, No DW_FORM_block* DW_AT_call_value for DW_TAG_call_site child DIE 0x444ea3 [in module d:\usr\eli\utils\gdb-8.1.90\gdb\gdb.exe].
     During symbol reading, Multiple children of DIE 0x446df5 refer to DIE 0x446b0a as their abstract origin.
     During symbol reading, Multiple children of DIE 0x446e39 refer to DIE 0x446b0a as their abstract origin.

This is a '-O2 -gdwarf-4 -g3' build using GCC 6.3.0.  Is any of these
messages important?

Thanks.

Re: GDB 8.1.90 available for testing

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

Eli> Other that that, the build went cleanly.  The new GDB binary, when
Eli> invoked on itself, reports the following DWARF-related issues:

Eli>      During symbol reading, unsupported tag: 'DW_TAG_unspecified_type'.

This is https://sourceware.org/bugzilla/show_bug.cgi?id=17271
It is probably harmless.

Eli>      During symbol reading, Member function "~_Sp_counted_base" (offset 0x3ef4f6) is virtual but the vtable offset is not specified.

This is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37237
It's an ongoing problem with no resolution in sight.  It affects
gdb users sometimes:

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


[...]

Eli> This is a '-O2 -gdwarf-4 -g3' build using GCC 6.3.0.  Is any of these
Eli> messages important?

I don't know about the others offhand.  I would guess that they are GCC
bugs, perhaps minor ones.

Tom

Re: GDB 8.1.90 available for testing

[Eli Zaretskii]

> From: Tom Tromey <tom@tromey.com>
> Cc: Joel Brobecker <brobecker@adacore.com>,  gdb-patches@sourceware.org
> Date: Thu, 19 Jul 2018 08:36:33 -0600
> 
> >>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
> 
> Eli> Other that that, the build went cleanly.  The new GDB binary, when
> Eli> invoked on itself, reports the following DWARF-related issues:
> 
> Eli>      During symbol reading, unsupported tag: 'DW_TAG_unspecified_type'.
> 
> This is https://sourceware.org/bugzilla/show_bug.cgi?id=17271
> It is probably harmless.
> 
> Eli>      During symbol reading, Member function "~_Sp_counted_base" (offset 0x3ef4f6) is virtual but the vtable offset is not specified.
> 
> This is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37237
> It's an ongoing problem with no resolution in sight.  It affects
> gdb users sometimes:
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=15975

Thanks for the pointers.  Truth be told, I'm quite surprised that some
of these are known for 10 years...

Re: GDB 8.1.90 available for testing

[Eli Zaretskii]

Ping!  Should anything be done about the last warning I describe
below?

> Date: Wed, 18 Jul 2018 19:13:39 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> CC: gdb-patches@sourceware.org
> 
> > From: Joel Brobecker <brobecker@adacore.com>
> > Date: Wed,  4 Jul 2018 09:22:02 -0700 (PDT)
> > 
> > I have just finished creating the gdb-8.1.90 pre-release.
> > It is available for download at the following location:
> > 
> >     ftp://sourceware.org/pub/gdb/snapshots/branch/gdb-8.1.90.tar.xz
> > 
> > A gzip'ed version is also available: gdb-8.1.90.tar.gz.
> > 
> > Please give it a test if you can and report any problems you might find.
> 
> I've built this with mingw.org's MinGW.  I found one problem in
> libiberty (which I will report separately), and I saw 3 warnings while
> compiling GDB sources:
> 
>        CXX    infrun.o
>      In file included from infrun.c:26:0:
>      inferior.h: In function 'void handle_vfork_child_exec_or_exit(int)':
>      inferior.h:533:39: warning: '*((void*)(& maybe_restore_inferior)+20).scoped_restore_current_inferior::m_saved_inf' may be used uninitialized in this function [-Wmaybe-uninitialized]
> 	{ set_current_inferior (m_saved_inf); }
> 					    ^
>      infrun.c:929:6: note: '*((void*)(& maybe_restore_inferior)+20).scoped_restore_current_inferior::m_saved_inf' was declared here
> 	   maybe_restore_inferior;
> 	   ^~~~~~~~~~~~~~~~~~~~~~
>      In file included from inferior.h:49:0,
> 		      from infrun.c:26:
>      progspace.h:285:47: warning: '*((void*)(& maybe_restore_inferior)+16).scoped_restore_current_program_space::m_saved_pspace' may be used uninitialized in this function [-Wmaybe-uninitialized]
> 	{ set_current_program_space (m_saved_pspace); }
> 						    ^
>      infrun.c:929:6: note: '*((void*)(& maybe_restore_inferior)+16).scoped_restore_current_program_space::m_saved_pspace' was declared here
> 	   maybe_restore_inferior;
> 	   ^~~~~~~~~~~~~~~~~~~~~~
> 
>    Same warnings were in GDB 8.1; ignored.
> 
>        CXX    symfile.o
>      symfile.c: In function 'void set_objfile_default_section_offset(objfile*, const section_addr_info&, CORE_ADDR)':
>      symfile.c:2114:14: warning: types may not be defined in a for-range-declaration
> 	for (const struct other_sections *objf_sect : objf_addrs_sorted)
> 		   ^~~~~~
> 
> The first two I saw in GDB 8.1 and reported back in January.  I
> believe the conclusion was that we disregard these warnings?
> 
> But what about the 3rd one?

Re: GDB 8.1.90 available for testing

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

>> CXX    symfile.o
>> symfile.c: In function 'void set_objfile_default_section_offset(objfile*, const section_addr_info&, CORE_ADDR)':
>> symfile.c:2114:14: warning: types may not be defined in a for-range-declaration
>> for (const struct other_sections *objf_sect : objf_addrs_sorted)
>> ^~~~~~
>> 
>> The first two I saw in GDB 8.1 and reported back in January.  I
>> believe the conclusion was that we disregard these warnings?
>> 
>> But what about the 3rd one?

I think this is a gcc bug.  This looks related:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79566

Simon occasionally fixes these by removing the 'struct' keyword.
This seems fine since it isn't really inconvenient and people may be
using the buggy versions of gcc.

This particular spot was fixed on git master in revision ff27d0737ef0.
I think it would be fine to cherry-pick that to the branch.

Tom

Re: GDB 8.1.90 available for testing

[Eli Zaretskii]

> From: Tom Tromey <tom@tromey.com>
> Cc: brobecker@adacore.com,  gdb-patches@sourceware.org
> Date: Sun, 29 Jul 2018 12:42:59 -0600
> 
> >>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> CXX    symfile.o
> >> symfile.c: In function 'void set_objfile_default_section_offset(objfile*, const section_addr_info&, CORE_ADDR)':
> >> symfile.c:2114:14: warning: types may not be defined in a for-range-declaration
> >> for (const struct other_sections *objf_sect : objf_addrs_sorted)
> >> ^~~~~~
> >> 
> >> The first two I saw in GDB 8.1 and reported back in January.  I
> >> believe the conclusion was that we disregard these warnings?
> >> 
> >> But what about the 3rd one?
> 
> I think this is a gcc bug.  This looks related:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79566
> 
> Simon occasionally fixes these by removing the 'struct' keyword.
> This seems fine since it isn't really inconvenient and people may be
> using the buggy versions of gcc.
> 
> This particular spot was fixed on git master in revision ff27d0737ef0.
> I think it would be fine to cherry-pick that to the branch.

Thanks, I've now cherry-picked that commit to the 8.2 branch.