SLN / RLN bug with -e option

[Songbird]

Pretty sure this is a bug. Not sure if it's been reported before.

 

When I use the -e option, SLN and RLN put the COF header before of the assembled code. ALN puts the COF header after the code. Net result: you can't execute a COF file as-is; you'd have to manually strip off the header first then relocate it to the proper address.

 

Now, this doesn't actually affect me, because I wasn't intending to build a COF file; I was just copying parms from old ALN batch files I was using 10+ years ago, and ran into this issue when I tried to load and execute the code. Once I removed the -e option, I'm getting the code I wanted.

[omf]

as far as i am aware smac and sln aren't actively in development any more

 

you would probably be better off ditching that and moving to rmac and rln, at least these are still maintained and more likely to get bug fixes

[omf]

.

Edited June 13, 2016 by omf

[Shamus]

I know that I never used that before, and didn't wouldn't have known what the correct behavior was even if I did. Thanks for reporting this, now I can fix it.

 

EDIT: Can you supply your copy of ALN so I can see exactly what it's doing? It may be that it's not writing the header but writing the symbol table. Also, what was the full command line you were using for ALN?

Edited June 13, 2016 by Shamus

[Songbird]

I'm using the old Atari-supplied ALN from 1995. I can supply it if you need it, but AA doesn't allow users to post *.exe files as attachments so send me a PM with your email address if you like. Command lines look like this:

 

aln -n -v -v -g -e -l -a 9FD000 x 3e00 -o prog_aln.bin prog.o

 

rln -n -v -v -g -e -l -a 9FD000 x 3e00 -o prog_rln.bin prog.o

 

If I drop the -e and switch to either sln or rln, it looks like it's doing the correct thing. But with -e, you can see that the code (which starts with $21FC1234) gets shifted down past a small COF header. Also note that the Atari-made COF info is much more extensive than what sln / rln appear to be doing.

 

I've attached the actual binary outputs from both of the above command lines. It's a pretty tiny program I'm writing, so there's not much to it.

 

Thanks to SubQMod and Reboot and associated hobby developers for making these awesome tools available!

prog_aln.bin

prog_rln.bin

Edited June 14, 2016 by Songbird

[ggn]

Hi,

 

Just had a quick look at the 2 binaries you posted. You're correct - rln seems to be adding the coff header and aln doesn't. But I don't see aln adding the coff header after the code as you said - it would have been kind of surreal if it did (or probably a bug ). What follows after your code is in fact the debugging symbol table.

 

In any case I took a look at rln yesterday and it seems a trivial thing to fix - I'm sure shamus is already on the case .

[Songbird]

I guess what I was calling the COF header is the section where it has the text, data, and bss labels. Both files have that, but in different order relative to the code binary. And yes, the prog_aln file has the complete symbol table following it as well. So there are actually two differences between the ALN output and the RLN output.

[Shamus]

Just have to verify what ALN is doing, then a fix will be forthcoming.

 

EDIT: Just having a quick look at the two binaries shows that RLN doesn't seem to honor the -n flag with COF output; also clearly doesn't output the full symbol table either. So should be a relatively easy fix, just have to verify ALN's behavior.

Edited June 14, 2016 by Shamus

[Shamus]

Seems that RLN was not respecting the -n (suppress header output) and -l (add local symbols) flags; should be fixed now. New builds of RMAC/RLN are up here:

 

http://virtualjaguar.kicks-ass.net/builds/

 

Thanks for the report Carl!

[Songbird]

Thanks for the quick fix! Output from rln looks much better now.