lifting-bits / dds

Dr. Disassembler
35 stars 9 forks source link

Add support for recognizing and propagation error conditions #6

Closed pgoodman closed 3 years ago

pgoodman commented 3 years ago

We should be able to mark functions as being no-return, e.g. _Exit, exit, abort, __assert_fail, etc.

We should propagate error-ness as follows:

Eventually, we'd also want to augment error flows with:

Error flows should be omitted from the usual control-flows, as they are guaranteed to error.

stevenagy commented 3 years ago

Should error / no-return EA's be constructed as edgetypes?

pgoodman commented 3 years ago

No, I think it's a relation / property that you'd model. So here's an example of how you could start:

; Tells us whether or not the execution of an the instruction at `EA` is
; guaranteed to lead to an error. An error could be code that can't execute
; (i.e. a non-decodable instruction), or could be something far down the
; line like a jump into a `hlt` instruction.
#local leads_to_error(EA)

; Base case: Something like `foo ; <junk>` where `foo` is a normal instruction.
leads_to_error(InsnEA)
  : instruction(InsnEA, INSN_NORMAL, _)
  , raw_transfer(InsnEA, ToEA, EDGE_FALL_THROUGH)
  , !plausible_instruction(ToEA).

; TODO: more base cases.

; Inductive case for fall-throughs.
leads_to_error(InsnEA)
  : instruction(InsnEA, INSN_NORMAL, _)
  , raw_transfer(InsnEA, ToEA, EDGE_FALL_THROUGH)
  , leads_to_error(ToEA).

; TODO: More inductive cases.
stevenagy commented 3 years ago

I think the following should cover the cases you mentioned above: https://github.com/lifting-bits/dds/blob/master/dds/datalog/instruction.dr#L14 (and onwards).

stevenagy commented 3 years ago

Closing as the following commits address this for now: https://github.com/lifting-bits/dds/commit/ef5ec7220e0f42eb6159d0a287b3dceea142e703 https://github.com/lifting-bits/dds/commit/65c033a8641f3120f0cfe7620f3fceacff2b7fb5