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