[RuntimeDyld] Don't try to allocate sections with alignment 0.

[zturner]

Summary

ELF sections allow 0 for the alignment, which is specified to be the same as 1. However many clients do not expect this and will behave poorly in the presence of a 0-aligned section (for
example by trying to modulo something by the section alignment). We can be more polite by making sure that we always pass a non-zero value to clients.

This was discovered when running the LLDB test suite on Linux with a debug build of LLDB / LLVM, and we had several hundred failures do an assertion triggering in MathExtras.h where we tried to call llvm::alignTo(Size, Align=0, ...).

I don't really know this code at all, so I'm not sure if the problem is that the JIT was generating a 0-align section in the first place, but this does at least faithfully match the ELF spec, while also fixing all of the bugs in LLDB's test suite.

[lhames]

Nice catch. LGTM. Thanks Zach!

llvm/trunk/lib/ExecutionEngine/RuntimeDyld/RuntimeDyld.cpp

RuntimeDyldImpl::emitSection(const ObjectFile &Obj,
   unsigned PaddingSize = 0;
   unsigned StubBufSize = 0;
   bool IsRequired = isRequiredForExecution(Section);
   bool IsVirtual = Section.isVirtual();
   bool IsZeroInit = isZeroInit(Section);
   bool IsReadOnly = isReadOnlyData(Section);
   uint64_t DataSize = Section.getSize();
 
+  // An alignment of 0 (at least with ELF) is identical to an alignment of 1,
+  // while being more "polite".  Other formats do not support 0-aligned sections
+  // anyway, so we should guarantee that the alignment is always at least 1.
+  Alignment = std::max(1u, Alignment);
+
   StringRef Name;
   if (auto EC = Section.getName(Name))
     return errorCodeToError(EC);
 
   StubBufSize = computeSectionStubBufSize(Obj, Section);
 
   // The .eh_frame section (at least on Linux) needs an extra four bytes padded
   // with zeroes added at the end.  For MachO objects, this section has a