[LLVMdev] [lld] memory leaks.

[Sean Silva]

On Wed, Nov 26, 2014 at 2:38 PM, Harsh Vardhan Dwivedi <
hdwivedi at codeaurora.org> wrote:

> Hi all,
>
>
>
> Can lld be used as a library as well? Also, is it possible to dump the
> fully linked IR code of the final program along with the program binary? I
> know llvm-link can link the IR but can we embed llvm-link functionality in
> lld to automatically dump alongside object code, the full program IR as
> well?
>

This is all in the roadmap, but is not currently implemented.

-- Sean Silva


>
>
> Regards,
>
>
>
> Harsh
>
>
>
>
>
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
>
>
>
>
>
> *From:* llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] *On
> Behalf Of *Rui Ueyama
> *Sent:* Wednesday, November 26, 2014 1:01 PM
> *To:* Jean-Daniel Dupas
> *Cc:* LLVM Developers Mailing List
> *Subject:* Re: [LLVMdev] [lld] memory leaks.
>
>
>
> On Wed, Nov 26, 2014 at 9:16 AM, Jean-Daniel Dupas <devlists at shadowlab.org>
> wrote:
>
> Hello,
>
> While working on lld code, I encountered a couple of memory management
> issues.
>
> If lld should be usable as a library, I assume it should not leaks any
> memory when performing a single link pass (UniversalDriver::link(arc,
> argv)).
>
> Actually, after calling that function, I got some major leaks. I may be
> wrong, but I think there is 3 major leaks.
>
> - One of the main leak is in FileArchive. When calling the find() method,
> FileArchive returns a non-owned pointer that is never deleted by the
> caller. The problem is that find() is a virtual method but does not
> properly define who is responsible of the returned pointer. So some
> implementations return a pointer to internal storage, and other
> implementation (FileArchive) returns a pointer without owner.
> Maybe a way to fix that issue is to tell that the pointer returned by
> find() must never be freed, and make sure the FileArchive (and other
> classes implementing find()) managed the memory of the returned file
> objects.
>
> - One other leak is Mach-O specific. TrieNode (in
> MachONormalizedFileBinaryWriter) uses a SmallVector to store its children.
> But TrieNodes are allocated using a llvm bumpPtr allocator, and so are
> never ‘deleted'. While the memory used by the TrieNode is properly released
> when the allocator is destroyed, the SmallVector destructor is never called
> and so the contained TrieEdges leak.
>
> - The third major leak source is the SimpleReferences stored in
> SimpleDefinedAtom (and subclasses). At least on Mach-O, MachODefinedAtoms
> are allocated using a llvm bumpPtr allocator, and so suffer the same issue
> than TrieNode. The SimpleDefinedAtom destructor is never called, and so the
> vector of SimpleReference defined in SimpleDefinedAtom is never deleted.
>
> Should I fill some bug report for theses leaks ?
>
>
>
> Yes, please. All memory leaks need to be fixed.
>
>
>
>
>
>
> -- Jean-Daniel
>
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141126/8e132f13/attachment.html>