Wrongly calculated expressions with cross-section labels #3

New Issue

Open

opened 2024-02-29 16:57:22 +02:00 by ggn · 0 comments

ggn commented

2024-02-29 16:57:22 +02:00

Owner

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.

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.

0001-Partial-fix-for-223-calculating-expressions-with-lab.patch

3.9 KiB

No Label

No Milestone

No project

No Assignees

1 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: rmac/rmac#3

No description provided.