Re: [ANNOUNCEMENT] GDB 8.2 released!

Tom Tromey
2018-09-09T18:36:49Z

>>>>> "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