Jump to content

SLN / RLN bug with -e option


Recommended Posts

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. :D

Link to comment
Share on other sites

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 by Shamus
Link to comment
Share on other sites

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! :)



Edited by Songbird
Link to comment
Share on other sites



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 :).

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by Shamus
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...