Re: [PATCH 0/8] Add Rust language support

[Tom Tromey <tom@tromey.com>]

Tom> If anybody cares, I have a list of the ugly bits in gdb I encountered
Tom> while writing this series.  I think it's all generally well known
Tom> though.

Pedro> I'd be curious.

First, let me say a few words about the good parts.  It's easy to add a
new language.  You pretty much start with struct language_defn and work
out -- there are only a couple of small holes with this plan (see
below).  (FWIW I'm planning to update the wiki with my experiences.)

One thing I especially like is that it's possible to do the work
piecemeal.  I actually started by just copying the C language definition
and then replacing individual fields as desired.

Now, here's some stuff I ran into that was less good.

* struct expression is very hard to deal with.  The prefixifying step is
  bewildering.  The need to manually manage slots in the expression
  makes all the code error-prone, especially because multiple bits of
  code all have to be modified in sync.  Adding a new operation involves
  making operator_length do the right thing, and also updating two
  different expression dumpers.  Expression evaluation has to handle two
  special "noside" cases, and one of them, AFAICT, is just fallout from
  the weird way that struct expression is laid out.

  I think replacing all of this with a more ordinary AST-like expression
  object would be a big improvement.

* I found val_print pretty ugly as well.  Printing a value means
  implementing a function that take 8 arguments, basically a struct
  value split into pieces.  Exactly what all of these mean is obscure,
  at least if you haven't been involved in the depths of gdb for a
  while...  back in the day I had wanted to replace this with a printing
  API that simply passed around values, not exploded values; I think
  that remains a good idea.

* Relatedly, it was a bit of a puzzle to build an object and fill it in.
  I think the choices were to use pack_* and fill in the bits manually,
  or allocate on the inferior, use value_assign to fields, and then
  re-fetch the resulting value.  Also only strings and arrays can be
  automatically pushed to inferior memory, so for struct objects I ended
  up requesting the allocation by hand.

* There's no built-in way to create a struct type and lay it out.  This
  requires a bit of arch support in the form of knowledge of any special
  ABI rules.

* The character and string printing hooks in struct language_defn are
  poorly factored.  Printing a string is very complicated, enough so
  that I didn't want to duplicate all the code in rust-lang.c.  However,
  despite the fact that there are two different character-printing
  hooks, it's still not possible to print character escapes in strings
  using Rust syntax.

* Writing a parser currently involves a bunch of global state.  There's
  struct parser_state but it doesn't contain all the relevant state,
  like innermost_block (this one particularly offends me for some
  reason) or parse_completion.

* There are a few spots that are desirable to update when adding a
  language that aren't covered by any hooks in language_defn.  In this
  series this includes the patches to dwarf2read; the adding of the
  ".rs" extension (file extensions could be in an array in the
  definition); and the change to symbol_find_demangled_name.

* Although DWARF encodes namespaces, I think there's no way to get at
  this information after gdb has made its symbol tables.  For Rust I
  ended up reusing some C++ functions to manipulate symbol names.

Tom