This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug c++/19893] Synthetic pointers created from C++ references are broken
- From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Tue, 31 May 2016 18:58:19 +0000
- Subject: [Bug c++/19893] Synthetic pointers created from C++ references are broken
- Auto-submitted: auto-generated
- References: <bug-19893-4717 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=19893
--- Comment #11 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Martin Galvan
<martingalvan@sourceware.org>:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=3326303bf5ae4c92f2fbbff387ce231a16c1c8bf
commit 3326303bf5ae4c92f2fbbff387ce231a16c1c8bf
Author: Martin Galvan <martin.galvan@tallertechnologies.com>
Date: Tue May 31 15:54:01 2016 -0300
[PR gdb/19893] Fix handling of synthetic C++ references
https://sourceware.org/bugzilla/show_bug.cgi?id=19893
I've traced the main source of the problem to pieced_value_funcs.coerce_ref
not being
implemented. Since gdb always assumes references are implemented as
pointers, this
causes it to think that it's dealing with a NULL pointer, thus breaking any
operations
involving synthetic references.
What I did here was implementing pieced_value_funcs.coerce_ref using some
of the synthetic
pointer handling code from indirect_pieced_value, as Pedro suggested. I
also made a few
adjustments to the reference printing code so that it correctly shows
either the address
of the referenced value or (if it's non-addressable) the "<synthetic
pointer>" string.
I also wrote some unit tests based on Dwarf::assemble; these took a while
to make
because in most cases I needed a synthetic reference to a physical
variable. Additionally,
I started working on a unit test for classes that have a vtable, but ran
into a few issues
so that'll probably go in a future patch. One thing that should definitely
be fixed is that
proc function_range (called for MACRO_AT_func) will always try to
compile/link using gcc
with the default options instead of g++, thus breaking C++ compilations
that require e.g. libstdc++.
gdb/ChangeLog:
* dwarf2loc.c (coerce_pieced_ref, indirect_synthetic_pointer,
fetch_const_value_from_synthetic_pointer): New functions.
(indirect_pieced_value): Move lower half to indirect_synthetic_pointer.
(pieced_value_funcs): Implement coerce_ref.
* valops.c (value_addr): Call coerce_ref for synthetic references.
* valprint.c (valprint_check_validity): Return true for synthetic
references. Also, don't show "<synthetic pointer>" if they reference
addressable values.
(generic_val_print_ref): Handle synthetic references. Also move some
code to print_ref_address.
(print_ref_address, get_value_addr_contents): New functions.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/implref.exp: Rename to...
* gdb.dwarf2/implref-const.exp: ...this. Also add more test
statements.
* gdb.dwarf2/implref-array.c: New file.
* gdb.dwarf2/implref-array.exp: Likewise.
* gdb.dwarf2/implref-global.c: Likewise.
* gdb.dwarf2/implref-global.exp: Likewise.
* gdb.dwarf2/implref-struct.c: Likewise.
* gdb.dwarf2/implref-struct.exp: Likewise.
--
You are receiving this mail because:
You are on the CC list for the bug.