[PATCH] [RuntimeDyld] Make ObjectBuffer/ObjectFile -> ObjectImage conversion a static method.

[David Blaikie]

I'm not sure I know enough about the actual code here to have high
level semantic suggestions, but one nit:

  std::unique_ptr<ObjectImage> Obj(std::move(InputObject));

seems unnecessary - you could just use the parameter directly (rename
it to "Obj" for example)

At some point I guess createObjectImageFromFile will return a
unique_ptr? (so you don't have to call reset with the result in
RuntimeDyld::loadObject(ObjectFile*))


Curiosity:

What does Dld->loadOObject(std::move(InputImage)) do? It's odd that it
takes an ObjectImage and returns one - does it return the same object?
Why not just have it take the thing by reference rather than taking
and returning ownership?


On Wed, Mar 5, 2014 at 11:20 AM, Lang Hames <lhames at gmail.com> wrote:
> Hi All,
>
> I would like to ensure that the target architecture for a
> RuntimeDyldImpl instance is known at construction time. Once this is
> possible, target specific logic (relocations/stub management) can be
> pushed down into the target specific subclasses, rather than living in
> large switch statements. This will improve both performance and
> readability.
>
> To support this work, this patch changes the way ObjectImages are
> constructed from ObjectFiles and ObjectBuffers: it replaces virtual
> methods on RuntimeDyldImpl with static methods on the relevant
> subclasses (RuntimeDyldELF, RuntimeDyldMachO). All the information
> needed to call the correct subclass method is already available at the
> call sites, so we don't lose any flexibility by switching to static
> methods here.
>
> Cheers,
> Lang.
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>