Search code examples
javaandroidbytecodedalvikdex

Dex debug_info format

While looking at a dex file, I noticed that in debug_info_item associated with each code_item, it is possible to have:

  • DBG_END_LOCAL without any DBG_START_LOCAL with the same register before it
  • DBG_START_LOCAL for a register that already has a debug info name defined and not yet closed (though this happens much more rarely)

I don't understand how I'm supposed to parse these cases. Is there something I'm not understanding about the debug_info_item format (https://source.android.com/devices/tech/dalvik/dex-format.html)?

Also, just to make sure, am I right that:

  • The DBG_START_LOCAL and DBG_END_LOCAL instructions define a debug name just for the instructions within the address range, and a jump instruction out of that range would make the name go away, even if the instruction pointer doesn't pass through the address pointed to by DBG_END_LOCAL
  • A register is used for just one variable, and there shouldn't be different debug names for the same register inside the same function
Solution

  • The parameter registers are all implicitly locals, so you can have a DBG_END_LOCAL with no DBG_START_LOCAL for a parameter register. In the case of a DBG_START_LOCAL for an "existing" local, I would imagine you just implicitly end the previous local and start the new local.

    But keep in mind that the debug info is informational only. There's nothing that verifies that it is structured properly, or really even makes sense. e.g. an obfuscator could add nonsense debug info without causing the dex file to fail verification when it is used.

    For example, I recently fixed a bug in baksmali related to start/end locals for register values that were out of range for that method.