This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Fix crash with empty Rust enum
>>>>> "Simon" == Simon Marchi <simon.marchi@polymtl.ca> writes:
>> + if (rust_empty_enum_p (type))
>> + error (_("Cannot access field of empty enum %s"),
>> + TYPE_NAME (type));
>> +
>> const gdb_byte *valaddr = value_contents (lhs);
>> struct field *variant_field = rust_enum_variant (type, valaddr);
Simon> I was wondering about this case (the STRUCTOP_STRUCT one). Would it
Simon> not work to let code go in the standard code path and let GDB not find
Simon> the field?
No, because the crash happens in rust_enum_variant.
Maybe I could change rust_enum_variant so that the callers can do this.
I'll look.
Simon> With the calls to error() as you wrote it in your patch, one
Simon> suggestion would be to include the name (or field number) of the field
Simon> in the error. In the case of a complex expression, it could help spot
Simon> the mistake (since the name of the enum type is not likely to appear
Simon> in the expression).
Good idea.
>> +# PR rust/23626 - this used to crash. Note that the results are
>> +# fairly lax because most existing versions of Rust (those before the
>> +# DW_TAG_variant patches) do not emit what gdb wants here; and there
>> +# was little point fixing gdb to cope with these cases as the fixed
>> +# compilers will be available soon
>> +gdb_test "print empty_enum_value" \
>> + " = simple::EmptyEnum.*"
>> +gdb_test "ptype empty_enum_value" "simple::EmptyEnum.*"
>> +# Just make sure these don't crash, for the same reason.
>> +gdb_test "print empty_enum_value.0" ""
>> +gdb_test "print empty_enum_value.something" ""
Simon> Is it possible (and worth it) to put some tighter checks, but kfail
Simon> them based on the compiler version?
Yeah. I am actually going to do something like this soon for other
tests that are already failing. I wasn't sure I wanted to put the test
suite changes into the 8.2 branch but I guess it wouldn't hurt.
Tom