Mark swift sections as 1 byte aligned

[mundaym]

The C compiler on some platforms (such as s390x) assumes that the
data pointed to by symbols meets certain alignment requirements.
The swift sections do not necessarily meet these alignment
requirements so this change adds alignment attributes to them to
force the compiler to emit the instruction sequences and relocations
required to address unaligned data.

This fixes a 'R_390_PC32DBL target misaligned' warning issued by
gold on s390x.

[jrose-apple]

Hm. Do we actually have alignment constraints on these sections? Will this mess with those?

[jckarter]

I think they're all at least four-byte-aligned. What alignment does s390x normally assume for global variables? It shouldn't hurt anything to assume they're less aligned here, though.

[mundaym]

s390x normally assumes 2-byte alignment for global variables. We ran into this issue because the length of one of the sections was an odd number of bytes meaning that the end symbol wasn't 2-byte aligned. If the start of each section is guaranteed to always be 4-byte aligned then we could just add the __aligned__(1) attribute to the end symbol.

It won't hurt on x86 to assume a lower alignment on both the start and end symbols though. I don't know if it will affect the code generation on arm. I suspect arm assumes a 1-byte alignment for global char arrays, which would mean this change would have no effect.

[compnerd]

@jrose-apple it shouldn't mess with any other alignments. Because these will be coalesced into the section, the highest alignment in the section will determine the data alignment. The symbols being marked with 1-byte alignment here are actually local to the file, so the loading of the pointer is the only thing which should be impacted. I agree with @jckarter - I don't think that this will harm anything.

[jrose-apple]

@swift-ci Please test

[compnerd]

@jrose-apple - any reason to not just merge this?

[jckarter]

No, thanks for the ping!