search

kierenj / 0x10c-DevKit

0x10c DevKit
http://0x10c-devkit.com/
39 stars 4 forks source link

Disassembly stops when it encounters non-code #143

Closed icarroll closed 12 years ago

icarroll commented 12 years ago

The disassembly view is difficult to use with code that has data interleaved with it. It would be helpful if it did not stop disassembly with invalid opcodes. Also, it would be nice if the user could designate certain memory areas as data, so disassembly would not be attempted.

kierenj commented 12 years ago

Well, you're contradicting yourself there. Should it try to disassemble data (invalid opcodes) or not? The reason it stops currently is because past any invalid opcode, it's impossible to guarantee the correctness of following opcodes. Some of the data might be a valid opcode, or a valid multi-byte opcode, meaning all code from that point is then off-by-one (even for 'good' code). That means as soon as you hit a bad opcode, the rest should really be ignored. Marking ranges as data is OK, but much code will be self-modifying, meaning you'd run into strange problems down the line, potentially.

It would be easy enough/possible to make the changes you suggest, but I'm not convinced they are the right thing to do. Can you give an example case, and are you sure it won't end up being more confusing in most cases?

icarroll commented 12 years ago

Sorry if my comment appeared self-contradictory. I was trying to say that if the user marked a region as data, it could be disassembled as DAT statements instead of instructions.

In most cases the disassembly would re-synchronize within a few instructions, so only a few words would be disassembled incorrectly. I don't think self-modifying code would be a problem. If the PC wound up in a region the user had marked as data, the system could just mark the area with some kind of warning.

The reason I bring this up is I wrote a subroutine called "print this" which prints the text immediately following the JSR instruction, terminated by a zero word. When it returns, the PC is set to right after the end of the text. In addition, I tend to put static data near the subroutine which uses it, so many routines will wind up in between blocks of data.

kierenj commented 12 years ago

Humm, I'm not sure that disassembly view is what you want to be using here: long strings will result in a lot of scrolling and disassembly is really a fall-back for times when code matching a certain PC cannot be found. Is there a reason you're not using, or improvement to be made to, regular source view?

ghost commented 12 years ago

The default could be stopping, and there could be an option to keep on going.

icarroll commented 12 years ago

The reason I'm using the disassembly view is that my assembler is incompatible with devkit. I load my program in as DAT statements. Needless to say, that makes debugging somewhat difficult.

If you don't feel that it's important to support this mode of operation, I can respect that. However, it does mean that devkit won't be very useful for me.

kierenj commented 12 years ago

Oh, that sucks. I will add the option for the next release (may be tomorrow)..!

kierenj commented 12 years ago

It's added, but with a warning: if the view is left open while the program runs, any time memory is changed (up to a maximum of once per 1.5 sec), all of RAM will be re-disassembed, which could cause performance problems. Anyway it's in there for the next release :)