This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

PR symtab/14441 - rvalue references


Hi,

I'm trying to fix http://sourceware.org/bugzilla/show_bug.cgi?id=14441
by adding support for rvalue references.  I plan to contribute this if
I get it finished before anyone else fixes it, so I'll get a copyright
assignment for GDB filed with the FSF clerk.

My first attempt, shown in the attachment, was very simple:

* added an rvalue_reference_type field to struct type
* modified make_reference_type() to take an extra parameter indicating
whether the type was an rvalue reference or lvalue reference
* call the modified make_reference_type() when the debug info contains
DW_TAG_rvalue_reference_type
* adjust c_type_print_varspec_prefix() to print "&&" when type ==
TYPE_RVALUE_REFERENCE_TYPE (TYPE_TARGET_TYPE (type)) i.e. when the
reference being printed is the target type's rvalue_reference_type,
not its reference_type.

That worked well enough to fix the <unknown type ...> problem shown in
comment 2 on the PR, but didn't solve all cases.  Saying "print r" or
"ptype r" for an rvalue reference type displayed the type with a
single ampersand rather than two.

So my second attempt is more invasive, adding TYPE_CODE_RVAL_REF and
changing everywhere that uses TYPE_CODE_REF to also handle the new
type code.  This gets me closer, fixing how types are displayed so now
I get:

(gdb) n
10        X&& xrr = X();
(gdb)
11        return;
(gdb) p xrr
$1 = (X &&) @0x7fffffffdd2f: {<No data fields>}
(gdb) ptype xrr
type = struct X {
  public:
    X & operator=(const X &);
    X & operator=(X &&);
} &&

This is all great, but I'm not finished yet. I still get the wrong
output if I take the address of an rvalue reference:

(gdb) p &xrr
$2 = (X &&*) 0x7fffffffdd30

As with a normal (lvalue) reference I should get the address of the
reference's target, not the reference itself.

Before I continue altering every function that checks TYPE_CODE_REF,
is my approach the right one?  Is adding TYPE_CODE_RVAL_REF and
touching dozens of functions the best approach, or should I go back to
my first attempt and just fix the few places that need to handle
lvalue and rvalue references differently?

Attachment: patch-1.txt
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]