;##TRACE and ;##ASSERT not working with Altirra/MADS under wine

[freetz]

Hi everyone,

 

I just read Phaeron's great post on debugging using Altirra here:

http://atariage.com/forums/topic/216515-debugging-using-altirra/

 

This is just awesome, and even though Altirra doesn't run natively on my Mac and I have to use wine with all its GUI anomalies (from a Mac perspective ), I'm already sold to switch from Atari800MacX to Altirra/wine.

 

One thing I don't get to work, though, is using conditional breakpoints in source code using MADS, i.e. ;##TRACE and ;##ASSERT. Using MADS under Eclipse/WUDSN does generate three files (xex, lst and lab), and labels are correctly imported when I disassemble in the debugger. However, when I execute "bl" to list breakpoints, none of them are there. Can I manually load the .lst to see if the import works in the first place? Or is there something else I should consider?

 

And while we're at it: After some tweaking, Altirra runs fine from Eclipse/WUDSN the first time the emulator gets started, but when I use /singleinstance, Altirra complains about the path to the executable which in OSX notation starts with a slash and not a backslash. Altirra says that /User ist not a valid command line option and therefore does not load the executable anew. But as I said, upon first start, it's not a problem. Is there any way to fix this?

 

Thanks a lot in advance,

 

F.

Edited July 12, 2016 by freetz

[phaeron]

In current versions of Altirra, directives from symbol files no longer appear in the normal breakpoint list since they're in a special directives group. This change was made to avoid polluting the user breakpoint list. Use bl -a to list breakpoints in all groups. The directives are parsed from the .lst file.

 

For a MADS .lst file to be parsed:

• The first line must contain "mads " in lowercase (note the space).
• A line after that must contain "Source: ".
• The line with the directive must begin with a space, then a line number.

These should not be an issue, but it's worth checking your .lst file, especially if you are using an OS X native compiled version of MADS.

 

SInce Altirra is a Windows program even when running under Wine, all paths passed to it must be in Windows syntax with backslashes. If you are trying to pass a Unix/OSX style path to it with forward slashes, that isn't going to work. There's also a possibility of a bug in Wine; Altirra does some trickery when invoked in this mode to ensure that relative paths are handled correctly, by marshaling the current directory and the current path for all drive letters from the invoking process to the running process.

[freetz]

Thanks a lot for this really helpful reply!
I had checked for the breakpoints with "bl -a" as well, but to no avail. After looking at the .lst-file, it turned out that the first lines look like this:

mads 1.9.3
     1 FFFF> 02E0-02E1> 00 20				run start
     2
     3 = 0014						RTCLOK = $14

So it seems that the "Source: " line you mentioned is missing. I've upgraded to mads 1.9.9 downloaded from Peter's WUDSN site, but still to no avail. The -p parameter is listed as a command line option, but it seems to be ignored, either because MADS' function show_full_name is not (correctly) working/compiling on OSX or for some other reason beyond me.
EDIT: I added this line via the script below which I have to run anyway. Now both TRACE and ASSERT work like charm !


As for the style of paths, I've feared already that this was due to the different formats in Windows and Mac. I found this to be a solution that mostly accomplishes what I want:

1. In Eclipse, use these values under the Altirra tab:
application path: /some/path/to/altirra.sh
command line: ${runnerExecutablePath} "${outputFilePath}"
Note the double quotes and that no other command line options should be defined here, this will come later.

2. Create the file /some/path/to/altirra.sh and use this code:

#/!bin/bash
fullpath="${1//\"}"
lstfile=${fullpath%.xex}.lst
WineExec=/Applications/Wine.app/Contents/Resources/bin/wine
AltirraExec=/Applications/Altirra.app/Contents/Resources/wineprefix/drive_c/winebottler/Altirra.exe

sed "/mads /a\\
Source: $lstfile
" $lstfile > $lstfile.temp
mv $lstfile.temp $lstfile

cd "$(dirname "$fullpath")"
$WineExec $AltirraExec /singleinstance /run $(basename "$fullpath") &

I have installed Wine as an app and created an Altirra.app using Winebottler, but all the above script needs is a valid path to a wine installation and the localtion of Altirra. Put all command line options (such as /singleinstance) here in the last line rather than in Eclipse, as otherwise the bash script might be confused about what is $1, $2 etc. In any case, $1 needs to be the full path incl. filename of the xex-file.
The reason why this is important is that the path and/or filename of the xex-file might contain spaces and thus needs to be quoted. However, the leading and trailing quotes unfortunately remain when splitting the full path into path and file, so they have to be removed first (second line above).

With this, Altirra only sees the filename and not the path, so it runs the xex without complaining, and it's possible to reuse the previous instance etc. The only drawback is that after subsequent calls to Altirra, the wine executable remains in the background and you need to switch to it manually. Calling wine via OSX's "open -a" does not help because it ignores the preceding change of directory and sets the current path to presumably the location of the app. There might be a way how to set the focus of a program maybe based on its PID, but I haven't figured that out. Most possibilities I've tried rather started the actual wine configuration program, and did not bring Altirra to the foreground. But maybe some Mac pros have a better idea here?

Edited July 13, 2016 by freetz

[freetz]

double post

Edited July 13, 2016 by freetz