[biela]

Hello

I am having problems with executing disassembler from CodeLite:
"File not found or File error"

CodeLite 2GGA.JPG

Return code is 10 or 1.
I have tried with full path also, and with other files.
Windows XP platform.

Anyway, very good job here.

Thanks

[motorhead1991]

We:all have to look into that then

[ender11]

check paths in sad.ini - in my case, it was autocreated with wrong drive letters.

[tvrfan]

Hey, I didn't realise I could change the post title...... !!

Hmmm. I thought I stopped autocreate happening.

Anyway 3 things - please let me know any issues and I'll fix them.

1. Does it autocreate a sad.ini ?
2. if it does autocreate, it should set all the paths to the same as where sad is run from (that is, the default is to have everything in the same place).
3. Those paths should be correct, both Linux and Windows [ 'x:\..\...' versus '/home/user/...../...' ]

If it doesn't find files, then check -
1. in Linux, file names are case sensitive - I don't think this is true for windows ?
2. Filenames can only have one dot (because of the way I get the names out) but any other char except slash should be OK.
3. I could have messed up the 'join' (pathname/filename) in some cases ....
4. max path+filename is 256 chars.

also -
you can move sad.ini into another directory if you wish - then run < SAD -c dirpath> without trailing slash, where sad.ini is in dirpath
(this is what I use to have several versions at once, but only one set of bins and dir files).

The idea was to have a command option <SAD -w> to write a default sad.ini config file, but I was focussing on getting bin listings correct....

SAD -h should give help info ......

I also intend to have a 'wrapper' for windows to get the GUI back, which will run the console prog.
Not done yet, having fun with Win API interface !

Oh - yes. It doesn't care what you call the exe file, so don't be afraid of renaming it to something shorter (like SAD.exe)

I posted version 3.02 to github ....

[tvrfan]

Just for a statement of where I'm at with the GUI, here is as far as I got (without Borland, direct Win32 API calls)

No ,it's not finished yet, just does the basic file lookup and responds to clicks.

Basic but it works, rename this txt file to an exe ! (attachments can't be .exe on this blog, which is a good thing...)

w32Wrap.txt

I need to add the config file (sad.ini)

[jsa]

Here are quick and dirty _difino examples of version info added to the output file headers.

Message file. This one is 2GGA to see it worked or errored.

Msg_V_text.png

List file

List_V_text.png

[jsa]

1. Does it autocreate a sad.ini ?

For your info.
With a code::blocks x86 built exe of V3.02, an ini is not generated when built or a disassembly run is done. I am dragging the bin file and dropping it on the sad.exe file. Win 7 x64 within windows explorer.

If it doesn't find files, then check -
1. in Linux, file names are case sensitive - I don't think this is true for windows ?

Not case sensitive in Windows.

[motorhead1991]

Here are quick and dirty _difino examples of version info added to the output file headers.

Message file. This one is 2GGA to see it worked or errored.
Msg_V_text.png



List file
List_V_text.png

Submit that to github. That's cool! :D

[jsa]

Submit that to github. That's cool! :D

the _Ino version, worthy of github submission, needs some smarts so a variable stores the version number and outputs to the command line and output file headers. Be better if it ended up in the exe properties as well.


How to submit it?
Which Repository and Fork?

[motorhead1991]

Submit that to github. That's cool! :D

the _Ino version, worthy of github submission, needs some smarts so a variable stores the version number and outputs to the command line and output file headers. Be better if it ended up in the exe properties as well.


How to submit it?
Which Repository and Fork?

If you have an account already, I'd be happy to add you to OpenEEC

[jsa]

jsa2340 on github

[motorhead1991]

jsa2340 on github

Sent. Push it to the development branch if you don't mind. Or fork it and go nuts

[jsa]

Ok, I put it in the Development Branch.

The location was at different line counts compared to V3.2 here.
The age in GIT of this core.cpp predates tvrfans latest V3.2.

[biela]

Hello

I have also installed Code::Blocks to make a try.
Then, after some cheks, the problem was inside sad.ini.
I forgot to add last "\" at the end of paths.
It is working now.

Thanks

[motorhead1991]

Ok, I put it in the Development Branch.

The location was at different line counts compared to V3.2 here.
The age in GIT of this core.cpp predates tvrfans latest V3.2.

Right, I need to bring in those bug fixes that TVR wrote up.

[jsa]

Some CARD code

Code: Select all

SAD V0.5
2068: 88,16,14          cmpw  R14,R16        
206b: db,0e             jc    207b           if ((uns) R14 < R16)  { 

SAD V3.02
2068: 88,16,14            cmpw  R14,R16          
206b: db,0e               jc    207b             if (R14 > R16)  {

Derived from the eec handbook page C15 / eec-iv_17.png file.
Substituted handbook values for R14 & R16.

Code: Select all

B-A
R14-R16
^ff-^80  Carry set 1 so JC will jump
^80-^80  Carry set 1 so JC will jump
^7f-^80  Carry clear 0 so JC will continue with next line of code

The description in intel 8096 literature, on how carry is set for compare, is the same I think.

I see other jump types are also output to the listing differently between SAD versions.

I'm seeing the old V0.5 as correct and V3.02 as having compare/jump bugs?

[tvrfan]

jsa - Yes, looks like a bug.

I did rewrite JC/JNC and many other bits, because there were several bugs in the source printout.
ops with zero, and 'base' register rollups into addresses, these and others with conditionals too.

I am almost ready to post the Windows GUI Wrapper for SAD, testing it now.
I made up the code by picking up lots of WIN32 API examples and cobbling them together ....
I'll keep this as a separate version number and branch - probably 0.1 to start with

OK - as soon as I've done that I'll go back and check here for bugs reported .

[jsa]

tvrfan, cool.

I see some differences with how SYM is displayed in the lst.

Code: Select all

SYM D100 "s.Some_Scalar_1"
SYM D101 "s.Some_Scalar_2"
etc

The first is shown in the lst but the second is not.
Maybe the first is loaded and the following are accessed by a R_++, not sure yet.

There is also something going on with D006, and user defined symbols and structures.
D006 and friends being part of engineering and calibration console addresses as well as tune data.

[motorhead1991]

tvrfan, cool.

I see some differences with how SYM is displayed in the lst.

Code: Select all

SYM D100 "s.Some_Scalar_1"
SYM D101 "s.Some_Scalar_2"
etc

The first is shown in the lst but the second is not.
Maybe the first is loaded and the following are accessed by a R_++, not sure yet.

There is also something going on with D006, and user defined symbols and structures.
D006 and friends being part of engineering and calibration console addresses as well as tune data.

I actually ran into that on 0.2 GUI. It's why I switched to manual mode.

WHile I'm thinking about it, let me merge 3.02.

[motorhead1991]

Ok, I put it in the Development Branch.

The location was at different line counts compared to V3.2 here.
The age in GIT of this core.cpp predates tvrfans latest V3.2.

It's all updated. AFAIK, it should be ready to go.

[tvrfan]

Noted.

I'm don't remember making any big changes to SYM area, although I did change the read/write storage setup a little bit.
if you do spot anything wrong, please check if it's a write symbol or a read as well.
(SAD will look for write sym first for something like SYM = <....>; and then a READ if no write sym defined)

if it's not displayed at all where it should be, I may have screwed up the address calculation of the relevant operands
(and I HAVE rewritten quite a bit of that)


----------------------------------
I see some differences with how SYM is displayed in the lst.

Code: Select all

SYM D100 "s.Some_Scalar_1"
SYM D101 "s.Some_Scalar_2"
etc

-------------------------------------------------
D006 et al.

I added an 'OK' list of certain addresses, which although they are technically illegal, are Ford defined locations.
For possible future ident/use (especially the later extra chips as in the Ford handbook)

d000-d00f is calibration console (in every bin I've seen so far)
0x1fff0 - 0x1ffff in multibanks is the DUCE chip ?

These don't report as "illegal address" any more, but are not scanned (even though they are CALLed like a subroutine)

I'll also look at that missing trailing backslash in the ini file paths. Should be able to sort that out too.

[tvrfan]

OK - I think I have found the JC and JNC problem, and the sad.ini path problem requiring slash at end.

(sad.ini is actually a code typo! For the geeks, I typed strrchr instead of strchr ... )

Can't find SYM problem so far, any more info would be welcome, to help me find it.

so probably a 3.03 coming soon ...

[jsa]

Looking back after motorheads comments, I see a couple of instances of the sym issue in V0.5, but different addresses to V3.02 it seems.

I think procede with 3.03, as I don't have a clear description.

[tvrfan]

I assume it misses the symbol in the source code printout.

Any of these would help....
Which binary ??
Any particular opcode or type (i.e. indexed, indirect,immediate ?)
is it linked to/close to a conditional jump ? (src is constructed from last PSW change opcode - a bit of fiddling about to get this right)

I have got an extra check for immediate as they are typically just numbers, but in some bins they are used for absolute addresses of
structures or values, so this code could have missed a spot (or two..).

Carry.

The Carry/Not Carry originally had "(uns) x > y" for 'unsigned' (Which is what carry is used for) but I've removed it as I don't think it matters
all that much for understanding. I've got a few 'C' like things, but can remove/add these to fit what you guys want. I took away the '(long)' from the divide and the shifts, but can put these back if you want.

[jsa]

Yeah, sorry I give you nothing till now, it was only an observation of something unusual to investigate.

Anyway, thougtplosion this morning and now I can give you a repeatable example.

As much pebkac as anything,

SAD has not discovered the use of or the size of the symbol during disassembly.

Sym not working.png

Declaring the size resolves the issue.

Sym working.png

Address order in the dir makes no difference.
In a perfect world SAD would see the next Sym and truncate the unknown length of the previous sym.

Carry......

From memory, the eec handbook and intel docs talk about carry behaving differently for compare & subtract vs the rest.
Hopefully you have it nailed now.

Long.....

A hint that a long is in play is helpful.

what you guys want

Speaking of wish list items, I like giving names with addresses in them, initially, rather than a sequential number.
Sub:B123
S.C456
F.C788
T.C78A

Test directive for above examples..

[tvrfan]

John,

Hmm.... whilst I see what you are saying, from my point of view, that behaviour is [currently] CORRECT.

Why ? From the design viewpoint (to explain)

a SYM is just a label for an address. It contains only the information <LabelName at Address>.
So....if an address is not referenced at all (i.e. it's printed as ??) then that address is UNKNOWN and SAD doesn't even look for a symbol.
just as you did, setting that address as a word will then make that address KNOWN, so it looks for a SYM.

Now, one of things I had pencilled in (and it's still in the SAD code I think, but not called) was a 'data structure detector' which would do a pattern analysis on ref'ed addresses followed by unknowns (especially if it's indexed or in a loop) to try to determine what it is. This would be how, for example, SAD could auto layout the injection table, which has a combination of vect (subroutine) addresses, RAM, and bitmasks. (have a look at A9L).

Similarly I had a 'gap' detector to try to find bits of code which aren't found (for whatever reason) and any possible data structs....

this also links in with my internal debate about static versus emulation analysis ....

So I agree on that fact it should do better in your example - - but not via symbol definitions !!

I hope that makes sense......

Carry - could be wrong here, but as I read it, carry flag is a physical overflow (or underflow) of the 16 bit word for all the opcodes.
(Yes, carry is reversed and treated as 'borrow' for some ops, e.g. subtracts, but same rule applies)
for shifts, it's when a bit is shifted out of the word (up or down).
For compares (= subtract without store) carry is when unsigned b > unsigned a in (a-b)
In signed compares the NEG flag is set as well/instead.
For multiplies its the same as shift up.
(Yes, you CAN argue, as I'm not 100% that's correct...but perhaps 90%)

Noted on the 'casts' (which is what 'C' calls them)
I'll put them back in and see what everyone reckons !! i.e. (long) (uns) (sign) perhaps (int) ?

Autonaming is currently just a sequential number (for each name), but yeah, could do an address type.

And you are all welcome to make suggestions where you want to see something different/better, and I'll consider it.

Thanks for feedback, it's great to get bugs reported !

[jsa]

John,

Hmm.... whilst I see what you are saying, from my point of view, that behaviour is [currently] CORRECT.
.....
just as you did, setting that address as a word will then make that address KNOWN, so it looks for a SYM.

Ok, we can just set as word or byte to tidy up.

Now, one of things I had pencilled in (and it's still in the SAD code I think, but not called) was a 'data structure detector' ...... (have a look at A9L).

Indeed, I have been looking at structure similarities between your a9l and card.

this also links in with my internal debate about static versus emulation analysis ....
...
I hope that makes sense......

Yes, understood.

I am agnostic, any analysis that generates good disassembly is a good thing.
I think some things like the 4,6,8cyl structures could be inferred as the last mop up run.

(Yes, you CAN argue, as I'm not 100% that's correct)

I'll go with 100%, I trust your experience.

Noted on the 'casts' (which is what 'C' calls them)
I'll put them back in and see what everyone reckons !! i.e. (long) (uns) (sign) perhaps (int) ?

Straight up I had noticed the loss UU, US, SS & SU from the lookup names.

All the cast info helps when pondering what is happening in a piece of code.
I don't mind abbreviation, if line length was the reason for removal.

[tvrfan]

Version 3.03 src now on github, and also posted windows build of SAD (console) and SADWIN which is the GUI wrapper
for it.

fixed JNC/JC showing wrong case in src printout.
fixed SAD.ini requiring trailing slash/backslash in pathnames (they are now optional).
added (long) and (uns) back to relevant opcode operands.

(Edited after jsa response)

I have just added a 64 bit Linux build as SADX, and an example sad.ini to go with it.
Please DON'T use this sad.ini on Windows as the path structure is totally different.

Linux is console only at the moment, but hey us UNIXphiles are well used to typing weird commands in a terminal window.......

[jsa]

Thank you.

[jsa]

If the sad.exe path is not defined in the ini and disassembly is initiated, sadwin will open an/other instance of Windows Explorer which displays an additional folder. The additional folder is not redisplayed if Win Ex is closed and restarted.