Re: [ANNOUNCEMENT] GDB 8.2 released!

[Tom Tromey <tom@tromey.com>]

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

CCing Mark Wielaard -- Mark see about 3/4 down...

Eli> Building GDB 8.2 with MinGW GCC 7.3.0 on MS-Windows, I see a warning:
Eli>        CXX    record-btrace.o
Eli>      In file included from exceptions.h:23:0,
Eli> 		      from utils.h:24,
Eli> 		      from defs.h:666,
Eli> 		      from record-btrace.c:22:
Eli>      ui-out.h: In function 'void btrace_insn_history(ui_out*, const btrace_thread_info*, const btrace_insn_iterator*, const btrace_insn_iterator*, gdb_disassembly_flags)':
Eli>      ui-out.h:197:18: warning: 'asm_list.ui_out_emit_type<(ui_out_type)1>::m_uiout' may be used uninitialized in this function [-Wmaybe-uninitialized]
m_uiout-> end (Type);
Eli> 	  ~~~~~~~~~~~~~^~~~~~
Eli>      record-btrace.c:792:35: note: 'asm_list.ui_out_emit_type<(ui_out_type)1>::m_uiout' was declared here
Eli> 	gdb::optional<ui_out_emit_list> asm_list;
Eli> 					^~~~~~~~

Eli> Is this a real problem?

No, I think this is a false positive from gcc.
You may want to file a gcc bug though I feel like there may be one already.

Eli> Also, a couple of places in remote-fileio.c use gettimeofday, which I
Eli> believe is deprecated under the recent versions of Posix; the
Eli> recommended replacement is clock_gettime.

Please file a bug.  I don't know how important this is or whether we
still care about porting to systems without that.  Maybe gnulib can help
here.

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

We discussed this one before.  It's a mild gdb bug.  Probably no
consequences.

Eli>    During symbol reading, macro `WCHAR_MIN' redefined at d:/usr/include/wchar.h:70;
Eli>     original definition at build-gnulib/import/stdint.h:561.
Eli>    During symbol reading, macro `WCHAR_MAX' redefined at d:/usr/include/wchar.h:71;
Eli>     original definition at build-gnulib/import/stdint.h:563.

Maybe a gcc bug.

Eli>    During symbol reading, const value length mismatch for 'std::ratio<1, 1000000000>::num', got 8, expected 0.

gcc bug.

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

We discussed this one before, too.  Longstanding gcc bug with no agreed
upon approach to resolving it.

I think my preferred approach would be for g++ to emit DWARF describing
the virtual table in its entirety.  This would let gdb know a bit less
about the ABI and would also maybe have some other benefits.  This is
the path we're heading down for Rust.

Eli>    During symbol reading, cannot get low and high bounds for subprogram DIE at 0x40c43e.

Eli>    During symbol reading, Child DIE 0x4433a0 and its abstract origin 0x448aff have different parents.

Eli>    During symbol reading, No DW_FORM_block* DW_AT_call_value for DW_TAG_call_site child DIE 0x447010 [in module D:\gnu\gdb-8.2\gdb\gdb.exe].

Eli>    During symbol reading, Multiple children of DIE 0x448d3a refer to DIE 0x448a80 as their abstract origin.

Eli>    During symbol reading, DIE 0x44aa21 and its abstract origin 0x446e69 have different tags.

I don't know about these.
Many times these complaints are due to DWARF oddities, but I feel there
are some complaints that represent gdb limitations.  So you have to dig
to find out.

I think most of these things would be good things for dwarflint to
check.  (Hi Mark.)

Eli> Anything here I should worry about?

Probably not.

Eli> Running "make -C gdb install-strip" fails:

Eli>      /bin/sh /d/gnu/gdb-8.2/install-sh -c -s ./contrib/gdb-add-index.sh \
Eli> 	     d:/usr/test-gdb-8.2/bin/$transformed_name.exe
Eli>      d:\usr\bin\strip.exe:d:/usr/test-gdb-8.2/bin/_inst.8116_: file format not recognized

Eli> It fails because Makefile attempts to invoke 'strip' on a shell
Eli> script.  I couldn't find any way to get past that except by hacking
Eli> gdb/Makefile to remove the offending portion, then installing that
Eli> shell script manually.  How does this work on Posix hosts?

gdb defines:

    INSTALL_SCRIPT = @INSTALL_SCRIPT@

... but install-only does not use it for gdb-add-index.sh.
I think this is just a bug.  It is used properly for gcore.

I didn't try the obvious patch, but maybe you could?

Tom