What to do about alignment of ELF objects

[Rui Ueyama]

I think the patch for LLVM looks okay, but not sure for the other one.

Your patch makes the linker to not be able to handle archive files
containing unaligned objects, or just makes it slower? If you cross-link an
executable for machines generous for unaligned accesses, say x86, on
not-so-generous machines, PowerPC for example, does it link fine?

On Wed, Apr 22, 2015 at 12:06 PM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> Currently the lower level APIs keep track of the alignment of elf
> objects in memory.
>
> At some point along the layers we switch to just using 2 byte
> alignment because of archives.
>
> One option is to just use 2 everywhere.
>
> Another is to copy the data to make it aligned. These patches do just that.
>
> I tested them by linking an X86_64 clang in an ppc64le machine. Having
> aligned access seems to help on ppc64le:
>
> trunk:
>
>  2.165775601 seconds time elapsed
>     ( +-  2.67% )
>
> patch:
>
> 1.979675092 seconds time elapsed
>    ( +-  2.96% )
>
> The main missing issue is the memory leak. The reason we can't have
> Archive just own the buffer for the unaligned members is that in lld
> we have
>
> ----------------------------------------
> FileVector loadFile(LinkingContext &ctx, StringRef path, bool
> wholeArchive) {
>   ErrorOr<std::unique_ptr<MemoryBuffer>> mb
>       = MemoryBuffer::getFileOrSTDIN(path);
>   if (std::error_code ec = mb.getError())
>     return makeErrorFile(path, ec);
>   std::vector<std::unique_ptr<File>> files;
>   if (std::error_code ec = ctx.registry().loadFile(std::move(mb.get()),
> files))
>     return makeErrorFile(path, ec);
>   if (wholeArchive)
>     return parseMemberFiles(files);
>   return files;
> }
> --------------------------------------
>
> So if --whole-archive is used, the Archive itself is freed and we then
> try to use the members.
>
> Should the registry have a place for putting Archives?
>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150423/eb534af2/attachment.html>