Re: [RFA] Handle dereferencing Rust trait objects

[Pedro Alves <palves at redhat dot com>]

On 11/15/2017 09:24 PM, Tom Tromey wrote:
> In Rust, virtual tables work a bit differently than they do in C++.  In
> C++, as you know, they are connected to a particular class hierarchy.
> Rust, instead, can generate a virtual table for potentially any type --
> in fact, one such virtual table for each trait (a trait is similar to an
> abstract class or to a Java interface) that a type implements.
> 
> Objects that are referenced via a trait can't currently be inspected by
> gdb.  This patch implements the Rust equivalent of "set print object".
> 
> gdb relies heavily on the C++ ABI to decode virtual tables; primarily to
> make "set print object" work; but also "info vtbl".  However, Rust does
> not currently have a specified ABI, so this approach seems unwise to
> emulate.
> 
> Instead, I've changed the Rust compiler to emit some DWARF that
> describes trait objects (previously their internal structure was
> opaque), vtables (currently just a size -- but I hope to expand this in
> the future), and the concrete type for which a vtable was emitted.
> 
> The concrete type is expressed as a DW_AT_containing_type on the
> vtable's type.  This is a small extension to DWARF.
> 
> This patch adds a new entry to quick_symbol_functions to return the
> symtab that holds a data address.  Previously there was no way in gdb to
> look up a full (only minimal) non-text symbol by address.  The psymbol
> implementation of this method works by lazily filling in a map that is
> added to the objfile.  This avoids slowing down psymbol reading for a
> feature that is likely to not be used too frequently.
> 
> I did not update .gdb_index.  My thinking here is that the DWARF 5
> indices will obsolete .gdb_index soon-ish, meaning that adding a new
> feature to them is probably wasted work.  If necessary I can update the
> DWARF 5 index code when it lands in gdb.
> 
> Regression tested on x86-64 Fedora 25.
> 
> 2017-11-15  Tom Tromey  <tom@tromey.com>
> 
> 	* symtab.h (struct symbol) <is_rust_vtable>: New member.
> 	(struct rust_vtable_symbol): New.
> 	(find_symbol_at_address): Declare.
> 	* symtab.c (find_symbol_at_address): New function.
> 	* symfile.h (struct quick_symbol_functions)
> 	<find_compunit_symtab_by_address>: New member.
> 	* symfile-debug.c (debug_qf_find_compunit_symtab_by_address): New
> 	function.
> 	(debug_sym_quick_functions): Link to
> 	debug_qf_find_compunit_symtab_by_address.
> 	* rust-lang.c (rust_get_trait_object_pointer): New function.
> 	(rust_evaluate_subexp) <case UNOP_IND>: New case.  Call
> 	rust_get_trait_object_pointer.
> 	* psymtab.c (psym_relocate): Clear psymbol_map.
> 	(psym_fill_psymbol_map, psym_find_compunit_symtab_by_address): New
> 	functions.
> 	(psym_functions): Link to psym_find_compunit_symtab_by_address.
> 	* objfiles.h (struct objfile) <psymbol_map>: New member.
> 	* dwarf2read.c (dwarf2_gdb_index_functions): Update.
> 	(process_die) <DW_TAG_variable>: New case.  Call read_variable.
> 	(rust_containing_type, read_variable): New functions.
> 
> 2017-11-15  Tom Tromey  <tom@tromey.com>
> 
> 	* gdb.rust/traits.rs: New file.
> 	* gdb.rust/traits.exp: New file.

Looks good to me, with a couple comments below.

> @@ -361,6 +362,11 @@ struct objfile
>  
>    struct psymbol_bcache *psymbol_cache;
>  
> +  /* Map symbol addresses to the partial symtab that defines the
> +     object at that address.  */
> +
> +  std::unordered_map<CORE_ADDR, partial_symtab *> psymbol_map;
> +

std::unordered_map + pointers (or really small objects) makes me
cry.  :-)  That has nasty memory overhead/footprint, with
unordered_map being a node container...

Can you say something about the number of elements that usually
ends up in this map in some reasonably sized Rust-using app (Firefox?)?

I'm assuming that you end up with many contiguous symbols pointing to
the same psymtab?  Would an addrmap (addrmap.h/c) be a good fit here?
Maybe not if we don't have the size of the psymbols handy when
we build this...  :-/

>    /* Vectors of all partial symbols read in from file.  The actual data
>       is stored in the objfile_obstack.  */


> +  CORE_ADDR vtable = value_as_address (value_field (value, vtable_field));
> +  struct symbol *symbol = find_symbol_at_address (vtable);
> +  if (symbol == NULL || !symbol->is_rust_vtable)
> +    return NULL;
> +
> +  struct rust_vtable_symbol *vtable_sym
> +    = reinterpret_cast<struct rust_vtable_symbol *> (symbol);

This reinterpret_cast looks like a big hammer here.  Why not static_cast?

> +  struct type *pointer_type = lookup_pointer_type (vtable_sym->concrete_type);
> +  return value_cast (pointer_type, value_field (value, 1 - vtable_field));
> +}


> --- a/gdb/symtab.h
> +++ b/gdb/symtab.h
> @@ -1061,6 +1061,11 @@ struct symbol
>       In this case the symbol is really a "struct template_symbol".  */
>    unsigned is_cplus_template_function : 1;
>  
> +  /* True if this is a Rust virtual table.  In this case, the symbol
> +     can be downcast to "struct rust_vtable_symbol".  */
> +
> +  unsigned is_rust_vtable : 1;

A symbol can't be both is_cplus_template_function and is_rust_vtable,
I think it'd be better long term if we merged the tag to a single
enum bitfield (with two bits).  But it's not that big a deal and
can always be done later.

So if we don't end up with too many symbols in the map that
could increase gdb's memory significantly, this is fine with me.
Fix the reinterpret_cast and you're good to go.

Thanks,
Pedro Alves