Unsupported GNU Extensions

[crzysdrs]

examples.tar.gz

Currently running into some failures while parsing some DW_OP values.

 Read(InvalidExpression(DwOp(253)))
 Read(InvalidExpression(DwOp(240)))

These appear to be DW_OP_GNU_uninit, DW_OP_GNU_variable_value. I think these are largely safe to ignore (so long as they are parsed).

Is there any approach to parse these (or other future/unimplemented extensions) without aborting parsing the entire DWARF file?

Ideally we'd be happy to limp along with a partial parse (with corresponding warnings) so long as we got a "best effort" parse (assuming these are as optional as they appear to be).

I did a little digging and got my testcases passing with this proposed workaround:

diff --git a/src/constants.rs b/src/constants.rs
index 1ed8c65..1914e5e 100644
--- a/src/constants.rs
+++ b/src/constants.rs
@@ -1267,6 +1267,7 @@ DwOp(u8) {
 
     // GNU extensions
     DW_OP_GNU_push_tls_address = 0xe0,
+    DW_OP_GNU_uninit = 0xf0,
     DW_OP_GNU_implicit_pointer = 0xf2,
     DW_OP_GNU_entry_value = 0xf3,
     DW_OP_GNU_const_type = 0xf4,
@@ -1277,7 +1278,7 @@ DwOp(u8) {
     DW_OP_GNU_parameter_ref = 0xfa,
     DW_OP_GNU_addr_index = 0xfb,
     DW_OP_GNU_const_index = 0xfc,
+    DW_OP_GNU_variable_value = 0xfd,

     // Wasm extensions
     DW_OP_WASM_location = 0xed,
 });
diff --git a/src/read/op.rs b/src/read/op.rs
index 0f9261a..b1c2d8d 100644
--- a/src/read/op.rs
+++ b/src/read/op.rs
@@ -807,6 +807,12 @@ where
                 }
                 _ => Err(Error::InvalidExpression(name)),
             },
+            constants::DW_OP_GNU_uninit => Ok(Operation::Nop),
+            constants::DW_OP_GNU_variable_value => {
+                // Unsupported
+                let _value = bytes.read_offset(encoding.format)?;
+                Ok(Operation::Nop)
+            }
             _ => Err(Error::InvalidExpression(name)),
         }
     }

[philipc]

You could maybe get away with that for DW_OP_GNU_uninit, but DW_OP_GNU_variable_value is important for correctness of the expression. Why not add full support for them? The nature of DW_OP extensions is that it's hard to skip unknown extensions, and there's not much we can do about that.

[crzysdrs]

I'm not against a full implementation of these particular extensions but unfortunately due to time constraints and limited familiarity with gimli internals / DWARF standards, I haven't attempted to determine exactly what that would entail. Ultimately a workaround that allows us to parse the full DWARF (even if it's mildly incorrect) is still useful to get some debugging support as opposed to none.

[philipc]

without aborting parsing the entire DWARF file

Is that happening because you're passing the entire file through the write convert code?

[crzysdrs]

Yes, we're basically calling Dwarf::from for the entire DWARF, applying changes with the convert_address function and writing it back out. So any hard-stop error prevents a complete Dwarf object from being created.

https://docs.rs/gimli/latest/gimli/write/struct.Dwarf.html#method.from

[philipc]

I'm very reluctant to add this sort of workaround that introduces incorrect handling. I'll have a look into supporting this properly.

[philipc]

#787 implements read/write support. It doesn't include evaluation support, but you don't need that.

[crzysdrs]

We do also use the evaluator to do stack unwinding in some circumstances. I'm not seeing these two extensisons show up in FDEs (at least in our test cases) but I suppose it's possible they might. In this case our failure mode would just be incomplete stack unwinding which definitely isn't as painful as failing to rewrite the DWARF file.

EDIT: We actually unwind based on the .eh_frame which I assume means it cannot include GNU extensions.

[philipc]

GCC's unwinder doesn't handle them so should be fine. Adding support for evaluating them shouldn't hard, but I don't have a way of testing it myself. I prefer to wait until someone needs it and can test it.