Created attachment 216 [details]
The patches!

I'll just paste the comment from the patch in expr.c:

					// This code addresses a very specific issue found when
					// assembling code in ALCYON mode and outputting ST PRG
					// binaries. At the time of assembling the start of
					// TEXT, DATA and BSS is 0 based. This is because we 
					// have no idea how big TEXT's size is going to be in order
					// to know what's the offset of DATA (same for BSS).
					// In general, most cases are handled during fixups as
					// at that point everything is known, so we can adjust the
					// address of labels etc etc. But in the case of calculating
					// an expression where some of its parts are in one section
					// and some in another, then this won't work. Since we
					// most likely are going to encounter expressions that
					// subtract cross-section labels (at least I cannot think
					// of any other use case), we add checks for these cases
					// here but only when fixups are happening. This will
					// simply add the start of a DATA or BSS label to it
					// before doing the subtraction, so then the distance
					// between the two labels will be calculated correctly.
					// Note that this doesn't work if the labels are fixed
					// up before this stage.

I've tried some other ideas, like:

- making a pass before fixups and correcting all the data/bss addresses, but this seemed to have triggered other problems in the regression suite
- also on the above, remove adding data/bss starts during fixups

Maybe these could work and I did an error while writing them, but I'm not sure. This fix was quickly written while I was knee deep in many other problems, and making a comprehensive fix would deter me from what I was doing. In the end I opted to have an incomplete solution than no solution at all.

P.S. Maybe this patch will be more robust if we move the "fixups_active" flag test after such cases have been detected in expr(). Then outside fixups time we could just stop processing the expression, forcing it to be calculated a second time during fixups, when this piece of code will allow the expression to (correctly) evaluate.

As an addendum:

Something like the following code for object file output (for example -fb)

	.text
    move.l  #(screenObjectList>>16)|(screenObjectList<<16),$F00020 // 10 bytes
	.bss
screenObjectList: ds.l 10

totally breaks things, as ResolveFixups() calls expr(), and since all symbols are defined at that point, all will be fine.

A possible fix to this is to add an extra step before calling expr() during fixups to check the token stream for all symbols in the expression, and bail if some are in different segments than the one ResolveFixups() is called with.