gdb/rust: fix crash for expression debug with strings
authorAndrew Burgess <aburgess@redhat.com>
Tue, 9 May 2023 11:13:02 +0000 (12:13 +0100)
committerAndrew Burgess <aburgess@redhat.com>
Wed, 10 May 2023 13:53:41 +0000 (14:53 +0100)
commit16c8122639ca0948f56fce125b3ad46e122d1edc
tree3d195c2ba019781cb3aac4df99285a9130bfdf82
parent6109320673fe30163b5d00d9e3a7f4e77befb22a
gdb/rust: fix crash for expression debug with strings

While working on another patch I did this:

  (gdb) set debug expression 1
  (gdb) set language rust
  (gdb) p "foo"
  Operation: OP_AGGREGATE
   Type: &str

  Fatal signal: Segmentation fault
  ... etc ...

The problem is that the second field of the rust_aggregate_operation
is created as a nullptr, this can be seen in rust-parse.c. in the
function rust_parser::parse_string().

However, in expop.h, in the function dump_for_expression, we make the
assumption that the expressions will never be nullptr.

I did consider moving the nullptr handling into a new function
rust_aggregate_operation::dump, however, as the expression debug
dumping code is not exercised as much as it might be, I would rather
that this code be hardened and able to handle a nullptr without
crashing, so I propose that we add nullptr handling into the general
dump_for_expression function.  The behaviour is now:

  (gdb) set debug expression 1
  (gdb) set language rust
  (gdb) p "foo"
  Operation: OP_AGGREGATE
   Type: &str
   nullptr
   Vector:
    String: data_ptr
    Operation: UNOP_ADDR
     Operation: OP_STRING
      String: foo
    String: length
    Operation: OP_LONG
     Type: usize
     Constant: 3
  evaluation of this expression requires the target program to be active
  (gdb)

There's a new test to check for this case.

Reviewed-By: Tom Tromey <tom@tromey.com>
gdb/expop.h
gdb/testsuite/gdb.rust/expr.exp