[cfe-dev] JIT - Resolve obj file without a main

[Lang Hames via cfe-dev]

Hi Bjoern,

Could you please tell me, if there is a way to allocate the memory for the
> codemodules more precise? I would like to allocate the memory for strings
> from a separated memory-pool. But how can I detect a string? The only
> moment I can do this is in "notifyObjectLoaded" via the names of the
> symbols. But than it is impossible for my to get the address of the
> symbols. I noticed that some strings are stored in .rdata, but this is no
> guarantee.


There is no easy way to do this at the moment, any it will always be
limited by what the object format allows (as you said: you need the object
format to tell you what's a string and what isn't, and they don't do that
in all situations).

If you can identify strings at the IR level you could do this by allocating
the strings in your own memory and marking the IR definitions as weak, but
this would also require LLVM to be more careful about picking strong
definitions, so it would require some non-trivial LLVM improvements. These
improvements are on the drawing board, but there is no schedule for them to
be implemented yet.

Cheers,
Lang.

On Wed, May 17, 2017 at 7:03 AM, <bjoern.gaier at horiba.com> wrote:

> Hi Lang,
>
> I'm using Windows. I was parsing an IR-File and added the Module to the
> ExectuionEngine. If I than searched for a function, I just got 0. But when
> the module had a main, I got an address. I solved the problem via a call to
> "generateCodeForModule". The JIT didn't even called my SymbolResolver in
> this special case.
>
> Could you please tell me, if there is a way to allocate the memory for the
> codemodules more precise? I would like to allocate the memory for strings
> from a separated memory-pool. But how can I detect a string? The only
> moment I can do this is in "notifyObjectLoaded" via the names of the
> symbols. But than it is impossible for my to get the address of the
> symbols. I noticed that some strings are stored in .rdata, but this is no
> guarantee.
>
> Kind regards
> Björn
>
>
>
> From:        Lang Hames <lhames at gmail.com>
> To:        bjoern.gaier at horiba.com
> Cc:        Clang Dev <cfe-dev at lists.llvm.org>, LLVM Developers Mailing
> List <llvm-dev at lists.llvm.org>
> Date:        16.05.2017 18:37
> Subject:        Re: JIT - Resolve obj file without a main
> ------------------------------
>
>
>
> Hi Björn,
>
> I don't recall ever seeing this behavior before. Can you describe the
> situation in more detail?
>
> Is this specifically for object files loaded via RTDyldLinkingLayer::addObjectSet,
> or does it apply to IR Modules without a main too?
>
> When you say the JIT won't resolve an address, do you mean that you can't
> find anything when you call findSymbol on the JIT, or that the JIT isn't
> calling your SymbolResolver back to find addresses?
>
> Was this for MacOS, Linux, or Windows?
>
> Cheers,
> Lang.
>
> On Fri, May 12, 2017 at 6:47 AM, <*bjoern.gaier at horiba.com*
> <bjoern.gaier at horiba.com>> wrote:
> Hello Lang,
>
> I noticed, if I load a obj-File without a main-function, the Jitter won't
> resolve any address. But if I have a main, everything works fine. Why is
> this so? Is there a way to stop this?
>
> Kind regards
> Björn
> Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB 9816,
> USt.ID-Nr. DE 114 165 789
> Geschäftsführer: Hiroshi Kawamura, Dr Hiroshi Nakamura, Markus Bode, Heiko
> Lampert, Takashi Nagano, Takeshi Fukushima.
>
>
>
> Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB 9816,
> USt.ID-Nr. DE 114 165 789
> Geschäftsführer: Hiroshi Kawamura, Dr Hiroshi Nakamura, Markus Bode, Heiko
> Lampert, Takashi Nagano, Takeshi Fukushima.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170523/84e9ede4/attachment.html>