What to do about alignment of ELF objects

Rui Ueyama ruiu at google.com
Thu Apr 23 12:17:59 PDT 2015


Did you actually confirm it's leaking?

A memory buffer of an archive file is co-owned by the archive file object
and file objects create out of it using shared_ptr. Look at
instantiateMember in lib/ReaderWriter/FileArchive.cpp. If you free all
files, the memory buffer should be freed as well.

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/e74718c4/attachment.html>


More information about the llvm-commits mailing list