donour

iTrader: (6)

It hardly makes any difference, I think. Porting it to C will be more work than it is worth. It's mostly just string and list manipulation. I'm not sure people will care about it taking 2s rather than 12.

d

RoadSpike

iTrader: (5)

Perhaps

If its not wanted i just wont bother.

Porting it to C would allow me to integrate it into a text pad like editor though much like IDA pro.

logic

iTrader: (2)

Yep. Writing it in C would have taken substantially longer, it would have been a much larger and less maintainable project, and all that would have been totally worth it for something with critical execution performance needs. I just don't see this as one of those cases; it's almost as quick as IDA on similar hardware right now, which is pretty satisfactory given I've spent very little attention on speeding it up (and have actually spent quite a bit of time adding junk over the last two days to slow it down ).

I actually considered doing this in Java originally, mainly because decent integration with Eclipse could be really interesting (and would allow me to punt completely on the UI), but I'd rather stab myself repeatedly in the eye than write miles of boilerplate. Did I mention I dislike Java?

Either wxPython or Tkinter ought to provide enough guts to make a halfway decent GUI for this at some point, but there's still infrastructure to write.

RoadSpike

iTrader: (5)

What about the .net languages? I write mostly in c# myself and the gui integration is cake.

logic

iTrader: (2)

Python is a .NET-hosted language, if that's really your thing. (Going back to the Eclipse idea, I could probably arrange Eclipse integration via Jython. Hmm. That's actually not a bad idea...)

But: if you want to re-implement the whole thing in another language, knock yourself out; don't let my preferences stop you! That's why I released it under the GPL: so other people can do with it as they please, as long as they release the source to their versions under a compatible license as well. Open source is great that way.

But I'm planning on continuing development of this version in Python, because platform portability is very high on my personal requirements list, and Mono just doesn't do it for me.

RoadSpike

iTrader: (5)

Cool i was just asking since i did a google search and found some sh2 disassemblers sitting around i thought maybe i could easily adapt one into a module for further use and combine it with the logic in your code. I'll definitely get back to this project right now I'm working on making JoT's virtual dyno a .net C# project so we can just open up the log files and select the run we want for dyno viewing etc etc.

This actually isn't taking me as long as I had dared hope I've only spent a day and I almost have a fully working log viewer dyno thingy not yet completed. I'm sure I'll get snagged by something soon I'm just not looking forward to it :P.

logic

iTrader: (2)

Yeah, I found those too. I was really hoping I could retrofit one of them to the task, but they're all variants on the same idea: a quick, lightweight binary-to-code translator, without any additional smarts (mainly, without the ability to follow branches). My first prototype for this project (which I ended up throwing away) worked in a similar manner.

The problem is, to be useful (or at least start approaching what IDA is capable of), you have to be able to follow branches, and to do that (for a few instructions), you have to track register contents, which is messy; you can't do it perfectly without effectively writing an SH2 simulator, so you have to decide what constitutes "good enough". Usefulness dictates that you need to generate labels for interesting locations as well, track data types (byte/word/long), and track cross-references, keeping everything in a suspended format that can be manipulated by code or the user.

If you end up wanting to re-implement this, I'd suggest looking over the segment/memory-model stuff to get an idea of how I'm doing internal representation of the whole mess (it could probably translate well to an ORM for state saving, although in Python, I'll probably just pickle it), as well as the SH2 register tracking and disp/label calculations to understand how I implemented that. There's quite a bit of room for improvement, but I'm happy with it so far.

(The ex-CS student in me is cringing a bit, though. )

WytWun

Thanks muchly for this Logic!

I'm using this to pull apart Magna (Diamante) ECUs, and have hit a problem with one ROM where it seems to be misinterpreting a register load such that it only pulls in a byte value rather than the long the opcode specifies. Things blow up because the byte value is 0, and it tries to (unsuccessfully) disassemble from address 0. I neutralised the addition to the disassembly work queue when the referenced location is 0, which allowed the disassembly to complete (only the 1 "odd" reference" found), but checking the ROM suggests that there's code that's not dissassmbled as a result.

If you're interested to follow this up, I can email the ROM image that provokes the issue and my debugging notes.

Cheers, Andy.

logic

iTrader: (2)

I'm definitely interested in trying to reproduce the problem; what ROM ID is it? If you can, please shoot me an email (esm at logic.net) with the ROM attached, and I'll take a peek.

Also, for reference: the repository has moved to github:

https://github.com/logic/sh2dis

There haven't been many changes since then, but it might be worth checking to see if the latest version still does it.

WytWun

I'll email the bits shortly. The ROM ID, if I've got it right, is 82450006; its from an 02 Australian Magna AWD.

When I encountered the problem, I went looking for the updates and was able to find and download the files from hg. Was hopeful when I saw some recent updates, but no dice

Cheers,
Andy.

PS: if you were able to update the link in your blog post to point to the hg repo, it might be easier for others to retrieve.