SMAC/SLN bug reports

[JagChris]

Thought I'd quote Linko and start a seperate thread for just bug reports on these tools for anyone interested in a bug list who wants to tackle fixing them.

 

I don't think it is honoring the .DPHRASE alignment directives correctly, it may also not be honoring the .LONG directives either which will present all kinds of wacky fail when the 68K tries to write to a long that is not long aligned, and as you have to pretty much always write long words to the DSP from the 68K this is going to cause all manner of problems.

 

This is my assessment based on the behaviour that I have seen when linked with SLN, which matches behaviour I had when there were alignment issues whilst I was working on the code.

Edited December 28, 2011 by JagChris

[LinkoVitch]

I am not sure that this is the bug tbh, I am still digging, it just feels that way. There is something wrong with the output from SLN, I am just not 100% at this time what. It feels alignmenty

[JagChris]

I am not sure that this is the bug tbh, I am still digging, it just feels that way. There is something wrong with the output from SLN, I am just not 100% at this time what. It feels alignmenty

 

Alright, I just felt we should document everything. Post more of course as you learn it.

[+DrTypo]

Hello,

 

I didn't tackle the alignmenty stuff but I fixed a very annoying bug when sln failed to link an object that is not in the current directory.

I attached the fixed windows exe and the patched sources.

The fix is very simple, I don't think I broke anything but I prefer that a few people here try it out before setting up an "official" website.

sln101.zip

Edited December 29, 2011 by DrTypo

[JagChris]

Thanks! This is the kind of input I was hoping for when making this thread.

[+DrTypo]

Hello,

 

now I'm into the alignmenty thing going on with SLN.

 

First I linked the u235se-0.17 demo with ALN. It works! And thank you DosBox. Win7 x64 doesn't like ALN.

Then I compared the .cof generated by SLN with the .abs generated by ALN. The file formats are basically identical, which made the comparison easy.

 

The whole binary blob generated by SLN is 16 bytes shorter than the one by ALN. There is indeed inside the big binary blob a sub-blob that starts 16 bytes ealier in the SLN output (0x0001A7D8 vs 0x0001A7E8).

But that's not our problem: this also happens in the earlier demos, which works with SLN. And I was able to spot the corresponding adress in the machine code. SLN computes the adress correctly.

 

However at offset 0x119, there is an 0xF4 in the SLN output where there is a 0xF0 in the ALN output.

Guess what happens if I change this 0xF4 to 0xF0 in the SLN output? Yep, the demo works.

I'm not fluent enough in machine code to tell what the hell it means. I'll grab a 68k disassembler to analyze this. Then I'll have to understand this whole linker business to fix the bug.

So I'm not quite done there yet.

[+DrTypo]

It's funny, when you look for a 68k disassembler you get tons of dead link.

I managed to get RecStudio: http://www.backerstr...com/rec/rec.htm

It's actually a decompiler but it does disassembling too.

And what is great is that it understands .cof files. It still is in beta and tends to crash though.

 

With this tool, I found out that it is the

lea U235SE_playback_rate,a0

at line 58 in main.s that is messed up by SLN.

In the disassembled code, I see that the symbol U235SE_playback_rate ends up with the same address as U235SE_playback_period.

 

The question is why?

Edited December 31, 2011 by DrTypo

[+DrTypo]

OK, I fixed the issue. It was not an alignmenty thing after all!

For those interested, it's in the function:

struct HREC *lookup(char *sym)

It's using the macro symcmp to compare symbols in a hash bucket.

The problem is that this macro is comparing 8 bytes.

So if symbols end up in the same hash bucket and their names have the same first 8 characters, panic ensues.

This was the case for the symbols U235SE_playback_rate and U235SE_playback_period.

 

I attached a zip file with patched source code and executable for Windows.

 

sh3-rg told me that people are working on improving smac/sln so I'll leave it at that for the moment.

sln102.zip

[JagChris]

OK, I fixed the issue. It was not an alignmenty thing after all!

For those interested, it's in the function:

struct HREC *lookup(char *sym)

It's using the macro symcmp to compare symbols in a hash bucket.

The problem is that this macro is comparing 8 bytes.

So if symbols end up in the same hash bucket and their names have the same first 8 characters, panic ensues.

This was the case for the symbols U235SE_playback_rate and U235SE_playback_period.

 

I attached a zip file with patched source code and executable for Windows.

 

sh3-rg told me that people are working on improving smac/sln so I'll leave it at that for the moment.

 

Thats excellent! And if you run into more bugs, dont stop taking the initiative just because others are working on it! Many hands make light work. And you're the first person to fix these bugs that we are aware of. So kudos to you! Its unfortunatete the forum wil only let me like posts once.

 

And Happy New Year everyone!

[JagChris]

It's funny, when you look for a 68k disassembler you get tons of dead link.

I managed to get RecStudio: http://www.backerstr...com/rec/rec.htm

It's actually a decompiler but it does disassembling too.

And what is great is that it understands .cof files. It still is in beta and tends to crash though.

 

You might consider sending these people an email letting them know you are using it for .cof files. Lets them know people are actually interested in that function. If they dont get any input that people are interested in that they might drop the feature in future versions.

[+DrTypo]

You might consider sending these people an email letting them know you are using it for .cof files. Lets them know people are actually interested in that function. If they dont get any input that people are interested in that they might drop the feature in future versions.

 

Good idea!

I sent an email to the guy developing this tool. I explained to him that his tool is useful to the Atari Jaguar community since we're using mc68k .cof files.

[JagChris]

Hello,

 

now I'm into the alignmenty thing going on with SLN.

 

First I linked the u235se-0.17 demo with ALN. It works! And thank you DosBox. Win7 x64 doesn't like ALN.

Then I compared the .cof generated by SLN with the .abs generated by ALN. The file formats are basically identical, which made the comparison easy.

 

The whole binary blob generated by SLN is 16 bytes shorter than the one by ALN. There is indeed inside the big binary blob a sub-blob that starts 16 bytes ealier in the SLN output (0x0001A7D8 vs 0x0001A7E8).

 

Is this another bug in SLN?

Edited January 1, 2012 by JagChris

[+DrTypo]

Is this another bug in SLN?

I don' know. I guess not. It's just that there is less padding in the output from SLN than from ALN. The sub-blob is still 16 bytes aligned so I don't see any ill effect from this.

[JagChris]

.

Is this another bug in SLN?

I don' know. I guess not. It's just that there is less padding in the output from SLN than from ALN. The sub-blob is still 16 bytes aligned so I don't see any ill effect from this.

 

 

 

Ill effect? If its not a bug its a 16 byte memory saving effect. Over a bigger program that would probably be even more savings

Edited January 1, 2012 by JagChris

[atarifan49]

I recently ran into an interesting learning situation during a large disassembly project. I had the following hex byte sequence that appeared three times in the code being disassembled:

 

23 20 00 00 00 6C

 

This translates to the following when disassembled:

 

MOVE.L #$6C,D0

 

Well, when I reassembled using SMAC the assembler would recognized that this can be optimized to a 2 byte code and produce:

 

70 6C

 

Unfortunately, there was no switch to force SMAC to not optimize such code. But it was easy work around to place a DC.W followed by a DC.L to just force the operand/operands I needed at those locations. I guess some of the Atari dev tools, whether for PC, Linux or the TT030 had some optimization issues with them.

 

So far, SMAC and SLN have been wonderful to use on my PC. I don't have to mess with VMWARE emulation just to run some dev tools.

 

Now if we could only have a way to improve the debugger tools (WDB or RDBJAG) and use the Skunk board for some serious in-system trace/debug work!

 

Glenn