Jump to content
IGNORED

RMAC/RLN


Orion_

Recommended Posts

Small bug in RMAC: in DSP code, a jr instruction to a non-existent label gives a "Error: relative jump out of range" error message instead of complaining about the label not existing :)

Maybe it was just testing you to see if you were paying attention? :D

  • Like 2
Link to comment
Share on other sites

Okay, here's a bug that's a bit more serious:

 

This:

.dsp
    load (r5+2), r0

generates the "Error: Malformed opcode [internal $07]" error message, as expected since r5 can't be used for indexed adressing.

(a clearer message would be a plus, but heh.)

 

However, this:

.dsp
foo .equr r5
   load (foo+2), r0

assembles with no warning, and actually generates this!

load (r7), r0

Yeah I know, it's invalid code. But this is not always obvious when your .equr is far way from the place you're actually using it :)

Edited by Zerosquare
  • Like 1
Link to comment
Share on other sites

Yeah I know, it's invalid code. But this is not always obvious when your .equr is far way from the place you're actually using it :)

 

Who would have thought actually using these tools would help debug them. Subqmod could have done with some developers back when he was active :)

  • Like 3
Link to comment
Share on other sites

Got a fix for the 1st one

   load (r5+2), r0

Generates the message:

test.s 4: Error: Attempted index reference with non-indexable register (r5)

Just wrapping my head around the second, and then I'll get a patch over to Mr Shamoo or see if I can still submit commits direct to the repo :)

 

(Having a productive day off so far :D )

  • Like 2
Link to comment
Share on other sites

Small bug in RMAC: in DSP code, a jr instruction to a non-existent label gives a "Error: relative jump out of range" error message instead of complaining about the label not existing :)

 

Is this under Windows? when I do a super simplistic test on my Linux box it segfaults for this (also not desirable behaviour, I just think Linux has it's shit together more with invalid memory access :) )

.dsp
pizza:
        nop
cheese:
        movei #0,r0
        jr      pizza
        nop
        jr      loop
        nop
        nop

I have stopped it seg-faulting but throwing an invalid expression error (which is a little more correct, but still not correct :) )

Link to comment
Share on other sites

  • 2 years later...
  • 9 months later...

ggn directed me here post about a possible bug with rmac/rln and the removers library.  I have attached an archive that has a bare bones example program that should be clear enough that playing a module in the removers library is causing the program to crash.  There is a log folder in the archive that contains logs for both mac and rmac builds for comparison.  It also includes makefile.config files for rmac and mac, for each toolchain, for comparison as well.

 

I also attached a current version of my rmac/rln/jlibc/rmblib tool chain setup script.  I have only tested this in Kubuntu 19.10, but it should work in any flavor of linux that has access to the Ubuntu repositories (needed for the cross compiler).  As for my old tool chain, if you want to test against this directly, I can get a link for the 200MB archive that has a prebuilt cross compiler and jlibc/rmvlib from 2010.  It also has prebuilt deb packages of a older kernel version that supports a.out binary emulation(this has been dropped in the most recent versions of the linux kernel).  This old tool chain has been my go to for jag dev for a decade now, but I would like to move to a tool chain that I know is buildable and usable in the future.

 

The reason why I think that rmac might be the source of the problem is because if I build the same program with my old tool chain (mac/aln) the program seems to work fine.  My old tool chain also uses a different version of the m68k cross compiler, but, from what I understand, because the source files for the sound engine seem to all be assembly files, the cross compiler doesn't actually interact with this source.  Its just linked with rln after rmac compiles the code.

 

I am not sure what other information might be helpful for this post, but if there is anything else that is needed to help troubleshoot this problem, let me know. Thanks!

10-29-19_mod_tracker_crash.zip 11-2-19_RMAC_RLN_JLIBC_RMVLIB_Setup_Scripts.zip

Link to comment
Share on other sites

23 hours ago, lachoneus said:

ggn directed me here post about a possible bug with rmac/rln and the removers library.  I have attached an archive that has a bare bones example program that should be clear enough that playing a module in the removers library is causing the program to crash.  There is a log folder in the archive that contains logs for both mac and rmac builds for comparison.  It also includes makefile.config files for rmac and mac, for each toolchain, for comparison as well.

 

I also attached a current version of my rmac/rln/jlibc/rmblib tool chain setup script.  I have only tested this in Kubuntu 19.10, but it should work in any flavor of linux that has access to the Ubuntu repositories (needed for the cross compiler).  As for my old tool chain, if you want to test against this directly, I can get a link for the 200MB archive that has a prebuilt cross compiler and jlibc/rmvlib from 2010.  It also has prebuilt deb packages of a older kernel version that supports a.out binary emulation(this has been dropped in the most recent versions of the linux kernel).  This old tool chain has been my go to for jag dev for a decade now, but I would like to move to a tool chain that I know is buildable and usable in the future.

 

The reason why I think that rmac might be the source of the problem is because if I build the same program with my old tool chain (mac/aln) the program seems to work fine.  My old tool chain also uses a different version of the m68k cross compiler, but, from what I understand, because the source files for the sound engine seem to all be assembly files, the cross compiler doesn't actually interact with this source.  Its just linked with rln after rmac compiles the code.

 

I am not sure what other information might be helpful for this post, but if there is anything else that is needed to help troubleshoot this problem, let me know. Thanks!

10-29-19_mod_tracker_crash.zip 484.55 kB · 3 downloads 11-2-19_RMAC_RLN_JLIBC_RMVLIB_Setup_Scripts.zip 2.86 MB · 3 downloads

 

First of all thanks ever so much for deciding to stick with rmac. We'll get it fixed, don't worry!

 

Unfortunately I don't have any Linux machines around as I've given up on Linux running smoothly on my machines at home. I'm trying to get WSL on Windows 10 updated to ubuntu 19.10 but it seems like it'll take some time. However I think that if you also upload the generated object files from all folders (rmac/mac/gcc) so I can have a "golden" reference I can then see the differences and when things go haywire. My gut feeling for now is that rln is at fault but I'd like to double check that the object files are also okay before going there.

 

(Yes I suppose I can find a copy of mac/aln and run them on dosbox but I think it'd be better if I had your copy of the object files altogether!)

  • Like 1
Link to comment
Share on other sites

 

Warning: data segment size of sound_data.o is not a phrase multiple
AddSymbols: for file sound_data.o
            t_bbase = $0
            d_bbase = $0
            o_bbase = $0
            tsize = $0
            dsize = $3A9E2
            bsize = $0
            reloc.tsize = $0
            reloc.dsize = $0
AddSymbolToHashList(): hptr=$E1D79510, sym="_song", ofile=$E1F2D8F0, value=$0, type=$7000000
Warning: data segment size of display.o is not a phrase multiple
AddSymbols: for file display.o
            t_bbase = $0
            d_bbase = $0
            o_bbase = $0
            tsize = $5CA
            dsize = $22
            bsize = $20
            reloc.tsize = $68
            reloc.dsize = $0

 

In the log file would appear to be an issue when linked in that the linker could be not padding.

  • Like 1
Link to comment
Share on other sites

GGN: If you are not using Hyper-V under Windows 10, I'd recommend grabbing VMWare Player (VMWare Desktop Free, or whatever it's called this week), and use that to spin up a Linux VM.. I use it myself for $dayjob and some Jagdev funs, works really well and you can always have a VM for a specific task.  It's free to use as long as not commercial use.  Might be easier than fighting whatever abomination MS has fused into Win10

Link to comment
Share on other sites

9 hours ago, ggn said:

 

First of all thanks ever so much for deciding to stick with rmac. We'll get it fixed, don't worry!

 

Unfortunately I don't have any Linux machines around as I've given up on Linux running smoothly on my machines at home. I'm trying to get WSL on Windows 10 updated to ubuntu 19.10 but it seems like it'll take some time. However I think that if you also upload the generated object files from all folders (rmac/mac/gcc) so I can have a "golden" reference I can then see the differences and when things go haywire. My gut feeling for now is that rln is at fault but I'd like to double check that the object files are also okay before going there.

 

(Yes I suppose I can find a copy of mac/aln and run them on dosbox but I think it'd be better if I had your copy of the object files altogether!)

Thanks for taking a look at this.  Here is a link of the archive I use to setup my old tool chain.  There is a readme folder with a readme inside, along with a prebuilt kernel with a.out emulation enabled.  This is if you want to test building with this toolchain yourself.  If the instructions aren't clear enough, let me know and I can step you through it on a VM if that is most convenient.

 

https://drive.google.com/file/d/10Zk1lYoclQo72DWjewiEvX_hmgvCip6G/view?usp=sharing

 

As for object files.  There are object files for the gcc cross compiler, jlibc (not current version), rmvlib, in this archive.  I only have the executables for mac/aln.  And now that I am thinking through this I feel a bit silly, I have actually never looked for the sources for these programs.  I was blissfully ignorant because they just worked until recently.  I guess I assumed that the source was so old and unable to build on a modern platform that it wouldn't be worth the effort to look into.

 

Here is an archive of the new rmac/rln tool chain, all object files included in the src folder.

 

https://drive.google.com/file/d/1aS0I6hJHXhtvrvkPtyu7UwyIJi8ZDm4q/view?usp=sharing

 

The gcc cross compiler is installed through a ppa repository.  But here is an archive of the files I could find for it in my root.  If you need install this like I did either use my setup script, or, follow steps 1 and 2 on this page. 

 

http://vincent.riviere.free.fr/soft/m68k-atari-mint/ubuntu.php

 

Just some copying and pasting in a terminal.  I wish building a cross compiler from source was this easy...

 

@Welshworrier

Nice catch!  I don't know if that is the source of the problem, but with my limited understanding it seems Jag does insist on phrase alignment in memory for some things.  I don't know exactly what things though...

Link to comment
Share on other sites

Awesome!  Glad I looked into where the Madmac sources might be at this point. 
 

http://www.dadhacker.com/blog/?p=1049

 

Turns out that rmac is the litteral progeny of Madmac.  (Also saw a familiar name in the comments section down in the comment section, @SubQMod). I know in various places on the web rmac was referred to as the grandchild of rmac.  I thought this was from a reversed engineered perspective, not from a derived from the same source code perspective. 

 

Thanks again to everyone involved for keeping this updated!

Link to comment
Share on other sites

Oh damn, I should have been more explicit when I mentioned "object files". I meant the object files created when you built the two examples, not the compilers themselves (so the .o files created like modTkrCrsh.o, gfx/data/gfx_data.o, etc). Sorry I put you into all that trouble really. Although it's not in vain as I'd probably end up asking you for the library files as well (rmvlib.a, jlibc.a, libgcc.a).

 

Yesterday I tried assembling the project's assembly files using rmac and mac. The resulting object files were byte for byte identical between assemblers. So it all points to linker problems (like @Welshworrier pointed out above).

 

16 hours ago, LinkoVitch said:

GGN: If you are not using Hyper-V under Windows 10, I'd recommend grabbing VMWare Player (VMWare Desktop Free, or whatever it's called this week), and use that to spin up a Linux VM.. I use it myself for $dayjob and some Jagdev funs, works really well and you can always have a VM for a specific task.  It's free to use as long as not commercial use.  Might be easier than fighting whatever abomination MS has fused into Win10

 

Jesus Christ no :). Never mind that my PC is an old fossil by now, I'm pretty much against running VMs for developing! As Mr xkcd put it eloquently:

 

xkcde.png

 

In comparison WSL is a much better compromise than the trainwreck that is called "spin a VM" - much less resources consumed, shared file system and the ability to run native linux binaries on Windows without spending tons of disk space and RAM :). I was in the process of bringing it up to the latest ubuntu yesterday, but thought to ask @lachoneus for the files to accelerate the process a bit.

 

No harm done though, I'll take a look at rln like I said.

Link to comment
Share on other sites

3 hours ago, ggn said:

Oh damn, I should have been more explicit when I mentioned "object files". I meant the object files created when you built the two examples, not the compilers themselves (so the .o files created like modTkrCrsh.o, gfx/data/gfx_data.o, etc). Sorry I put you into all that trouble really. Although it's not in vain as I'd probably end up asking you for the library files as well (rmvlib.a, jlibc.a, libgcc.a).

 

Yesterday I tried assembling the project's assembly files using rmac and mac. The resulting object files were byte for byte identical between assemblers. So it all points to linker problems (like @Welshworrier pointed out above).

No worries.  I should have though to pre-compile these programs for you, instead of just giving you the source.

11-4-19_mod_trkr_bug_compiled.zip

  • Like 1
Link to comment
Share on other sites

On 11/4/2019 at 6:13 PM, lachoneus said:

No worries.  I should have though to pre-compile these programs for you, instead of just giving you the source.

11-4-19_mod_trkr_bug_compiled.zip 1.22 MB · 1 download

Okay, many thanks for this, it really helped with my findings. So here's what I got:

 

1. The .o files you supplied that are assembled with rmac and mac are byte for byte identical. This proves that rmac is rock solid and (almost) a drop in replacement for mac - high five!

2. This also stands true for the .o sets of files I produced independently of yours. So we're two for two :).

3. Linking - geez, that proved a major source of pain. I really ought to add a patch to rln that validates search paths instead of blindly accepting them, someone has to get this right :/. As usual, it's no fun adding a path that you have a typo and then the tool proudly reporting that your requested file could not be found, leaving you scratch your head in order to understand if the relative path was wrong or there was a typo or whatever (ok, rant mode off now, sorry!)

3a. Once I sorted out all the files etc (in my usual style I just copy all .o and .a files into the build folder and let rln parse the files from there!) I created a linked .cof file that run on virtual jaguar without crashing - yay!

3b. Out of curiosity I then took your "mod_tracker_crash_rmac" and just pasted the object files and libraries that I used to link my build files and that also resulted in a working binary - double yay!

 

I went ahead and attached the winning combo of .o and .a files. Which leads us to takeaways:

 

1. Yeah we probably need some more work when it comes to user experience for rmac and rln. Bear with us!

2. I'm not sure what happens with your setup. Some file you link against seems to have an issue. I'd suggest you try linking with my set of object files and see if that works for you. If yes (I sincerely hope so!) then you can take it from there and check your build environment for the bad file(s) that produce the bad .cof.

3. Sadly I couldn't repro a crashing binary after all the above. So if you find the offensive file(s) it'd be interesting if you share them with us for further analysis into what went wrong

 

There we go, sorry for the wall of text but I hope this helps fixing your problem and hopefully we can put this unpleasant experience (for you at least) behind us!

object_files_and_libs.zip

  • Like 2
Link to comment
Share on other sites

@ggn Just to clarify, and to make sure I understand how you tested this.

 

You took the object files of the example program, the necessary .a file from gcc, and then with the two different sets of .a and .o files for jlibc/rmvlib from the two different tool chains I uploaded, and then did two different links with rln?  One linked .cof file with the object files from my old tool chain, and one linked .cof file with the new tool chain.

 

The reason why I ask, and why it's important to test both of these sets of object files, is that I am using two different versions of jlibc/rmvlib in each of these tool chains.

 

And now I realize I may have sent you out on a wild goose chase having you test rmac against two different versions of jlibc/rmvlib.  Sorry about that. 

 

I think I may have found a clue though.  I noticed that the object files from the rmvlib in your archive are from my old tool chain, built back in august of 2018.  So, thinking that it could just one object file that could be causing the problem, I decided to replace the object files from a newly built version of rmvlib one-by-one with the ones in your archive, until the program started to work correctly in the emulator.  After replacing just sound.o it started working.  So, to clarify, I replaced sound.o, built from the most current version of rmvlib, with sound.o file from your archive, built from some version back in august of 2018. Does this mean there is a problem with rmvlib in the most recent assembly code of sound.s?

Link to comment
Share on other sites

First of all, no worries about the supposed wild goose chase - it's all good!

 

As for which sound.o I used: well, I just unpacked the "Jaguar_linux_dev_setup_rv6.zip" and started looking for the filenames of the objects I wanted to link against. It might have been from the "old" folder or the "new" but I'm not sure. The thing is, all sound.o files in that archive (and there are 3 of them) are byte for byte identical between each other. I also did some byte comparisons between the files in the folders the 3 sound.o files are and the files in the .zip file I uploaded above. I still get byte match for all files.

 

Next thing I tried was to assemble sound.s with rmac myself. The resulting .o file isn't byte match identical to the archive's .o files. So that's progress I guess! I'll see what happens from here, there were quite a few changes that happened for v2.0.0 of rmac so it's not impossible that something upset the jrisc parts. I'll have a look and will report back when I have something. Stay tuned....

 

[EDIT] Now that I think about it: do you happen to know what version of rmac you used to assemble the sound.o in the archives? Or have I got it wrong and it was assembled using mac?

Edited by ggn
Clarification
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.

Guest
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.

Loading...
  • Recently Browsing   0 members

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