logic

iTrader: (2)

I figured this might be a good place to ask, since I know there's at least a few folks here dealing with both IDA Pro and gas (from GNU binutils; the KPIT tools for SH processors, specifically). I'm working on a rudimentary conversion script between IDA's "Produce File|Create ASM File..." output and something gas can actually assemble. I currently have a working build system that can take an IDA assembly file (with one catch), convert to gas format, and with a little manipulation, produce an identical ROM to what IDA started with.

The catch seems to be translating ".data.l" into something useful; while ".long" would seem to be semantically correct, it gets about halfway through my 96940011 disassembly, and starts belching out "Error: misaligned data" for any of my ".long <location>" lines.

An example might help: for the IDA output "off_F42: .data.l unk_9693", the translated version becomes "off_F42: .long unk_9693". Nothing really special, but those are the lines throwing errors. The problem doesn't actually crop up until the 3213th line into the disassembly, which suggests I'm doing something stupid elsewhere, and it's just appearing at this point (all of the prior entries assemble fine).

My sed command line looks like this so far: (Yes, I know it's simple-minded, but it does the job. I don't have a translation for ".sdata", since I'm not using that in the disassembly anywhere anyway.)

The problem shows up trying to assemble a basic "jump to entry point, hit c" disassembly, so it's an easily-repeatable problem. Any ideas would be appreciated.

tephra

iTrader: (6)

Options - > General
Anaylsys - > Target Assembler -> GNU AS

Hope this helps

logic

iTrader: (2)

Oh you have got to be kidding me. *bangs head on keyboard*

Thank you.

logic

iTrader: (2)

Apparently I did a pretty good job with that simple-minded sed script, because the output they produce natively is almost identical.

And it fails exactly the same way, which makes me wonder if I'm tripping a gas bug now. I'm on Linux doing this; is anyone else seeing a problem like this on Windows?

tephra

iTrader: (6)

Yeah I tried this quickly ages ago and gave up... :|

logic

iTrader: (2)

If I can dodge the alignment error (ie. by assembling a file full of nothing but ".byte" lines), with an appropriate "dd" I get a byte-for-byte identical version of the ROM that IDA started with, so I'm liking this approach; managing changes in source control suddenly became a whole lot more reasonable. I just need to figure out wtf is up with randomly throwing alignment errors. Hrm. I'll have to build my own binutils, see if that works any better. Possibly have to see if I can break the source up somewhat and build multiple objects for merging later.

Hmm. I wonder if the elf header generation is causing the misalignment? Or just a bad disassembly? Everything I'm reading about SuperH processors seems to indicate that they'll choke on misaligned data...

For anyone reading this, the KPIT tools on Windows throw the same errors. Yay. Is anyone building anything other than trivially small chunks of code with this?

tephra

iTrader: (6)

im using custom built GAS for my builds, then using a patch script to rip ASM from the hex file and put it into the ROM...

logic

iTrader: (2)

Found the problem; "opportunistic" disassembly, coupled with GAS being extremely strict about alignment. IDA insisted on labeling a ton of data as code offset references, and when GAS tried to compile that, it didn't care that those labels weren't actually code, it just assumed I'd find a way to run it somehow, and was letting me know I was doing something stupid. Amazing what you can figure out after a good night's sleep.

Once I work through this huge list of bogus references and clear them in IDA, I should have a fully buildable 96940011 disassembly; then I can start labeling/formatting more useful stuff. Thanks for the pointers, tephra!

logic

iTrader: (2)

Now this is weird. Relative movs appear to be "off-by-one".

An example of the code in question is "mov.l @(0x40, pc), r0". The native code in the ROM was "D0 10", but the code being produced by GAS is "D0 0F".

So, I guess what I'm wondering, is the problem:

1. how I'm invoking gas
2. how I'm disassembling with IDA
3. that I need to go back to high-level programming

*sigh* So close...

tephra

iTrader: (6)

hrmm not sure, what does the manual say "mov.l @(0x40, pc), r0" should equal in hex?

I would guess that your GAS may not be setup correctly

Cheers
D.

logic

iTrader: (2)

"D0 10" should be correct if I'm reading the manual correctly (0x10 * 4 == 0x40), so it looks like IDA is getting it right. I'm getting the same result ("D0 0F") just assembling that one line of code on both Linux (64-bit) and Windows (32-bit) (using KPIT's sh-elf build of binutils). It's also doing it with my own build of binutils 2.18.

I also have another oddball one-liner test case of "mov.w @(2, pc), r1" that constantly throws a "pcrel too far" error; change that 2 to a 3, and it builds, although incorrectly. It records "91 00" instead of "91 <disp>"; in the case above (2), it should be "91 01".

Both of these problems seem to center around PC-relative references. Changing the target processor (sh2e vs sh4 vs dsp, etc) doesn't seem to make any difference at all (not that I'd expect it to, but you never know).

I have to be missing something obvious here, especially if others are getting reasonable code out of their installations. More reading and searching for me.

logic

iTrader: (2)

Well, I finally had a chance to revisit this, months later. Using the latest build from KPIT/Renesas, I started getting a new error: PC-relative MOVs like the one above were throwing an alignment error, and refusing to assemble at all.

Change "mov.l @(0xXY, pc), r0" to "mov.l off_XYXY, r0", and viola, gas had no problem with it. (and produced the correct machine code) If I had to guess, I'd suspect that it's still mis-calculating pcrel offsets, and just hard-failing now; checking the binutils mailing list suggests they made a change in behavior here over the last few months.

So, I whipped up a quick script to translate all pcrel movs to their labeled version, and after fixing a few self-inflicted problems in my disassembly, I now have a fully re-assemblable (is that a word?) version of 96530006. Next up, I want to take the basic EcuFlash XML parser I wrote a while back, and see if I can use the IDA SDK python bindings to automatically label the tables in the XML for a given ROM. (A "mostly-complete" disassembly should be automatable as well by walking the interrupt vectors, especially if you pre-label everything prior to disassembly.)

Anyway, I'm rambling. Coming back to the original problem: is there a way to force IDA to present those mov instructions by offset name (valid gas syntax, but I don't think shasm would accept it) rather than as explicit PC-relative offsets? IDA seems to have fifty hidden ways to display anything, so I suspect this is just an area I'm still soft on.

logic

iTrader: (2)

One other thing my simple-minded script had to do: translate the RAM segment into something useful. Instead of this: I ended up with this: This ensures that the RAM segment is correctly referenced, and not included in the resulting object output. (Failing to add the @nobits to the .section instruction will result in a VERY large object output.)

Anyone know a way to get IDA to output this automatically? I suspect I can manually mangle the .section instruction just fine, but adding in a .org seemed to change the first instruction in the section instead of inserting a new one.

logic

iTrader: (2)

One more post, because I suspect I'm going to run out of time to work on this soonish. I've posted both the IDA script I've been tweaking, and an awk-based post-processor, up on the wiki, in case anyone else could find some use for them.

I'm wondering if a basic buildable assembly for each ROM would be a useful addition to the wiki? I can (mostly) automate the process of creating and testing these now, if someone would find value in them. (Not the IDA databases themselves, just the assembly output; anyone should be able to create a good IDA starting point from the script I posted, so I don't think there's a lot of value there.)

dokalanyi

Both scripts are no longer available. I'm looking for pcrel_filter.sh especially

I'm following https://www.evolutionm.net/forums/ec...-ecu-code.html and kind of stuck because I can't find that script