[llvm-dev] JIT and static constructors/destructors.
Lang Hames via llvm-dev
llvm-dev at lists.llvm.org
Tue Jun 26 14:49:43 PDT 2018
Hi Alex,
I think adding a method to RuntimeDyld to run the constructors (or retrieve
their addresses) would make sense, and should work on Linux and MachO. I
can't speak to COFF though.
This would be an improvement over the current utility code, as it would
support static constructors in pre-compiled object files too.
Cheers,
Lang.
On Tue, Jun 26, 2018 at 2:36 AM Alex Denisov <1101.debian at gmail.com> wrote:
> Hello everyone,
>
> The question is related to the recent "runStaticConstructorsDestructors()
> causes
> crash on exit" thread [1].
>
> I was curious if the constructors/destructors thing can be done directly
> via
> inspecting object files. Below is what I've found so far.
>
> On macOS, I was able to get symbols for constructors by looking at
> relocations
> at _mod_init_func. Then, I used the symbol names to retrieve addresses of
> actual
> constructors (after relocations were applied) and calling them.
> It worked well in this very case.
>
> On Linux, same relocations are located inside of .rela.ctors or
> .rela.init_array.
> I tried the same approach as with MachO, but not all symbols have names.
> I.e., there are just references to some code (e.g. .text.startup+0x280).
> So I cannot retrieve the address based on the symbol name.
>
> I assume there can be an API within RuntimeDyld that can give the address
> of
> a RelocationRef corresponding to a particular constructor relocation.
> In that case, it will work both for Linux and macOS. Probably on Windows
> as well.
>
> The question is: in what case this approach will not work?
> Note: I am only interested in a non-lazy JIT of a native code.
>
> Thank you,
> Alex.
>
> [1] http://lists.llvm.org/pipermail/llvm-dev/2018-June/124031.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180626/80ae6b09/attachment.html>
More information about the llvm-dev
mailing list