Finer control over placement of sections

[Stewmath]

The problem: I want to use ramsections, but I also want my ramsections to be in a specific order - I don't want the linker jumbling them up.

With sections, I can use the FORCE directive, but that doesn't really work with ramsections. So, here are the solutions I can think of:

• Allow FORCE with ramsections. This would require keeping track of the ORG for a specific slot/bank of a ramsection (assume it starts at 0 I guess?). Or, the linker could simply place FORCE'd sections first (unsorted) before doing the rest of the (sorted) sections.
• Add a flag to the linker to tell it not to sort sections at all.
• Use something like linkerscripts. This was rgbds's solution to the problem of fine control over section placement. While this would be more flexible, it might be a bit overkill since FORCE sections work ok for this purpose (though using FORCE won't give you full control between multiple object files, while linkerscripts would).

I'm currently experimenting with a refactored implementation of enums + ramsections + structs, so I could implement this if there's a consensus here.

[Stewmath]

Another idea: allow APPENDTO to work with ramsections. That would be the most flexible option short of linkerscripts.

[vhelin]

The APPENDTO solution sounds the best, so let's have it on the TODO list. 😀

[vhelin]

I’ll commit a solution to this tomorrow when I get back to my laptop, just added support for APPENDTO to .RAMSECTIONs, but wasn’t able to commit (forgot my phone and thus my Internet connection to the cabin)...

[vhelin]

What do you think, is it ok now?

[Stewmath]

Will try this out when I have a minute, syntax looks fine though.

[vhelin]

I don't think I paid enough attention to this issue before, for some reason. Anyway, I added a switch to WLALINK to disable section sorting.

With the latest sources you can also use FORCE with a .RAMSECTION, and change the priorities of sections in the linkfile... Has this issue been solved already or do we need to work on it a little more?

[Stewmath]

It seems I never found that minute to experiment with this even after 2 years =P

I tried using APPENDTO. It seems to ignore "ALIGN". IDK if that's easy to fix or not.

The "-nS" flag appears to work. Though now I'm curious what benefits I may be missing out on by not sorting sections? Does this have any effect on Free or Superfree ROM sections? If not I would probably prefer to use this.

One more thing. When converting my .ENUMs to .RAMSECTIONs, I now get this warning:

build/ages.o: code/bank0.s:1821: COMPUTE_STACK: The passed on SLOT changed from $0 to $2. This might have no effect, but just to let you know. Please check that the result of this calculation is correct.

Caused by this line of code (which performs arithmetic between a ROM address and a WRAM address):

ld hl,_initialThreadStates-(<wThreadStateBuffer)

I guess this is a reasonable sanity check, although believe it or not, I did have a reason for performing such a calculation. (Don't blame me though, I'm only disassembling the code!) Perhaps there could be a way to mute this type of error?

Appreciate your work lately :)

[Stewmath]

My particular use-case has another minor problem with this, in that even if sections are unsorted, it will still try to place sections within "gaps". For example:

.RAMSECTION "A" BANK 0 SLOT 2
wThing0: dsb $a0
.ENDS

.RAMSECTION "B" BANK 0 SLOT 2 ALIGN $100
wThing1: dsb $100
.ENDS

.RAMSECTION "C" BANK 0 SLOT 2
wThing2: dsb $40
.ENDS

In my case I would expect wThing2 to come after wThing0 and wThing1. But since there is a gap between sections A and B, section C is placed between them. What do you think? Is this correct behaviour? Personally I have no idea.

Now, I think I should mention that the only reason I feel I need multiple ramsections in the first place, is because I have no way to align data within a ramsection. If an ".ALIGN" directive existed within the ramsection - instead of just as a parameter when defining it - I feel this largely wouldn't be a problem, and I could just stuff everything into one section, without worrying about how the linker decides to sort the different sections.

I wonder how difficult this would be. I think the linker needs to know the size of a section before it's received, so I guess this would need to be done by the assembler. It might work if the section itself has the ALIGN directive in use. IE, with this:

.RAMSECTION "A" BANK 0 SLOT 2 ALIGN $100

The assembler should have enough information to support internal alignment up to a value of $100:

.RAMSECTION "A" BANK 0 SLOT 2 ALIGN $100

wValue1: db ; $c000

.ALIGN $20

wValue2: db ; $c020

.ALIGN $100

wValue3: db ; $c100

.ALIGN $200 ; ERROR: Assembler doesn't have enough information to handle this
.ENDS

The last line would be an error, I think, since we would need to use the linker to figure out how to align it. Although if the linker could do that, I guess that would be ideal, but it seems like that would be more complicated.

Thoughts on this?

[Stewmath]

Hold on - I'm clearly behind the times. I need to look at some of your more recent changes like the solution to #302.

[Stewmath]

Your solution to #302 is great and is exactly what I was looking for when I opened this issue 2 years ago, so thank you for that :) I did not read your most recent reply to this topic carefully enough.

With this solution in place I don't feel any need to use APPENDTO or the new "-nS" flag. I am still interested in a possible .ALIGN directive though, as well as muting the warning when doing arithmetic between different slots. These are separate issues though.

[vhelin]

The -nS flag to WLALINK stops all sections from being sorted so size and priority are ignored.

The

build/ages.o: code/bank0.s:1821: COMPUTE_STACK: The passed on SLOT changed from $0 to $2. This might have no effect, but just to let you know. Please check that the result of this calculation is correct.

should not be an error, only a warning. It doesn't break assembling/linking? I don't know about muting it as there might be cases where it might be a good warning to have around.

ALIGN doesn't really work outside .SECTIONs; Only .SECTIONs can be ALIGNed. Adding support for .ALIGN inside .SECTIONs would mean a completely new data structures and code and I have to admit I have no idea how to do that in the current framework. But adding ALIGN to .RAMSECTIONs would be much easier...

[vhelin]

And yes, if you feel like those issues you discussed here are worth a new feature, please open a new issue for them, separately. :) I'll make one for adding ALIGN to .RAMSECTIONs...

[vhelin]

In my case I would expect wThing2 to come after wThing0 and wThing1. But since there is a gap between sections A and B, section C is placed between them. What do you think? Is this correct behaviour? Personally I have no idea.

Yep, that's correct behaviour. WLALINK tries to pack everything as tight as possible. Perhaps we need another switch to disable this?

[vhelin]

I wonder how difficult this would be. I think the linker needs to know the size of a section before it's received, so I guess this would need to be done by the assembler. It might work if the section itself has the ALIGN directive in use. IE, with this:

.RAMSECTION "A" BANK 0 SLOT 2 ALIGN $100

The assembler should have enough information to support internal alignment up to a value of $100:

.RAMSECTION "A" BANK 0 SLOT 2 ALIGN $100

wValue1: db ; $c000

.ALIGN $20

wValue2: db ; $c020

.ALIGN $100

wValue3: db ; $c100

.ALIGN $200 ; ERROR: Assembler doesn't have enough information to handle this
.ENDS

The last line would be an error, I think, since we would need to use the linker to figure out how to align it. Although if the linker could do that, I guess that would be ideal, but it seems like that would be more complicated.

If we left this to linker we'd need new data structures and data handling, perhaps split .SECTIONs/.RAMSECTIONs into pieces with additional metadata that would let the linker know about .ALIGNs -> pretty big change...

But letting the assembler to do it like you described, that would work, but in a limited way. I'm not sure if it's worth the trouble to implement that as it works in special cases only...

[Stewmath]

I think you're right, you shouldn't worry about this. Linkfiles are a much more flexible solution for my case anyway, to the point that even the non-sorting flag feels unnecessary to me now.

EDIT: I mean don't worry about the linker order, as for the aligns we're discussing that in another issue...