Align mips crt .init/.fini sections to 4 bytes instead of 16

[arichardson]

Summary

New versions of LLD will fill any padding between different object
files with trap instructions so if any of the .init/.fini code is not
aligned to 16 bytes we will get crashes at runtime.
With this patch I can boot a MIPS64 world almost entirely linked with LLD.

I'm not sure whether using balign here is fine or whether I should adjust the
power of two align value.

Obtained From: CheriBSD

[emaste]

I suspect only crtn.S (i.e., the _init and _fini epilogues need the 4-byte alignment treatment.

[emaste]

It looks like other existing files all use .align, I would probably keep that consistent.

Oh, looking now it seems only mips and sparc64 have .align in crtn.S, other archs do not specify it at all. I think we could just remove it from crtn.S and rely on the fact that all objects' .init and .fini sections will be a multiple of the instruction alignment.

[jhb]

Did you test this? In CheriBSD we are definitely using the equivalent of .align 16. MIPS instructions are only 4-bytes, so instruction alignment as described in your latest comment would seem to imply that '.align 4' was redundant?

[jhb]

(FWIW, the last time I tried I couldn't get clang 8 to even build a 32-bit mips, I didn't try mips64 though)

[emaste]

From the gas manual,

The way the required alignment is specified varies from system to system. For the a29k, hppa, m86k, m88k, w65, sparc, and Hitachi SH, and i386 using ELF format, the first expression is the alignment request in bytes. For example `.align 8' advances the location counter until it is a multiple of 8. If the location counter is already a multiple of 8, no change is needed.

For other systems, including the i386 using a.out format, it is the number of low-order zero bits the location counter must have after advancement. For example `.align 3' advances the location counter until it a multiple of 8. If the location counter is already a multiple of 8, no change is needed.

My guess is that this started with .align 4 on sparc where it meant 4-byte alignment and was copied to MIPS where it meant 16-byte alignment, which is definitely not desired.

[arichardson]

In D18291#438254, @jhb wrote:

Did you test this? In CheriBSD we are definitely using the equivalent of .align 16. MIPS instructions are only 4-bytes, so instruction alignment as described in your latest comment would seem to imply that '.align 4' was redundant?

I'm pretty sure we use 4byte alignment (.balign 4) to ensure its aligned to one instruction.

[emaste]

In D18291#438263, @arichardson wrote:

In D18291#438254, @jhb wrote:

I'm pretty sure we use 4byte alignment (.balign 4) to ensure its aligned to one instruction.

My argument for just removing it is that if we're linking in an object file with an .init or .fini containing part of an instruction we're going to fail at startup (or shutdown) anyway so it doesn't matter. In cases where the objects are well-formed the alignment directive is redundant, and other architectures (except sparc64) don't specify it so MIPS ought not as well.

[arichardson]

In D18291#438265, @emaste wrote:

In D18291#438263, @arichardson wrote:

In D18291#438254, @jhb wrote:

I'm pretty sure we use 4byte alignment (.balign 4) to ensure its aligned to one instruction.

My argument for just removing it is that if we're linking in an object file with an .init or .fini containing part of an instruction we're going to fail at startup (or shutdown) anyway so it doesn't matter. In cases where the objects are well-formed the alignment directive is redundant, and other architectures (except sparc64) don't specify it so MIPS ought not as well.

I agree, dropping it should be completely fine since the individual files should implicitly have alignment 4. If not then the compiler is doing something wrong.

[jhb]

Hmm, never mind then. CheriBSD is using .balign but I assumed that meant some power-of-two thing (so .balign 4 == align to 16). Still didn't answer my question of if you ever tested this. :-P

[emaste]

In D18291#438275, @jhb wrote:

Hmm, never mind then. CheriBSD is using .balign but I assumed that meant some power-of-two thing (so .balign 4 == align to 16). Still didn't answer my question of if you ever tested this. :-P

Huh, it seems I had a draft reply here that I never submitted. The draft mentioned that I had applied the change to my WIP tree for all of the images I built, but I can't recall now if I actually booted a MIPS image with the change.