<div dir="ltr">Hi Andres,<div><br></div><div>I've just realised that we're going to need a change to the definition generator API in the long term: Right now it is called under the session lock, but we want to shift to calling it outside the lock and passing a lookup-continuation. This would allow definition discovery to take an arbitrarily long time without blocking forward progress on other JIT work.</div><div><br></div><div>I'm guessing your objective for now is to minimize churn, right? If that's the case I'll focus on moving to the continuation passing API on the orcv1-removal branch before I update the C API.</div><div><br></div><div>Alternatively if you don't mind some minor churn before LLVM 12 I'll focus on landing the C API in its current form, then landing orcv1-removal on the mainline, then I can work on the continuation passing update in the mainline.</div><div><br></div><div>-- Lang. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 29, 2020 at 5:26 PM Andres Freund <<a href="mailto:andres@anarazel.de">andres@anarazel.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
On 2020-09-29 13:58:35 -0700, Lang Hames wrote:<br>
> > Have the basics working. Should I open a PR to your branch for what I<br>
> > got so far?<br>
<br>
> Sounds good to me.<br>
<br>
Done, <a href="https://github.com/lhames/llvm-project/pull/2" rel="noreferrer" target="_blank">https://github.com/lhames/llvm-project/pull/2</a> .<br>
<br>
<br>
> The first is to expose more of symbol resolution. Postgres can be<br>
> > extended via dynamically loaded libraries, and we need to be careful to<br>
> > look up symbols in the correct library. In the generated JIT IR<br>
> > references to functions in such libraries use a distinguishable symbol<br>
> > name (see example below), indicating that they should not be looked up<br>
> > in the global namespace.<br>
> <br>
> <br>
> From the example code I guess the namespacing for symbols from external<br>
> libraries is something like: "<modulename>.<symbolname>" ?<br>
<br>
It's currently pgextern.<path_to_library>.<symbolname><br>
<br>
<br>
> This is what definition generators are for. We can add an API for attaching<br>
> generators and provide facilities to define a generator in C.<br>
> Here you'd want a generator with a map of module names to dylib<br>
> handles.<br>
> First you'd search for a handle for <modulename> (loading it if it didn't<br>
> already exist) then you'd dlsym <symbolname> in that handle.<br>
<br>
Ok, cool.<br>
<br>
<br>
> Related to that, when hitting this case I currently get, on stderr:<br>
> > JIT session error: Symbols not found: [<br>
> > pgextern./home/andres/build/postgres/dev-assert/vpath/src/test/regress/regress.so.pt_in_widget<br>
> > ]<br>
> > but currently that error is not bubbled up to the C API. There I just<br>
> > get:<br>
> > ERROR:  XX000: failed to look up symbol "evalexpr_0_0": Failed to<br>
> > materialize symbols: { (main, { evalexpr_0_0 }) }<br>
> <br>
> (obviously the first part is postgres code)<br>
> > Do you have thoughts on what that should look like?<br>
> <br>
> <br>
> We need an API to install an error reporter on the session: That's where<br>
> the SymbolsNotFound error will be delivered. I'll add that in a minute.<br>
<br>
Sounds good.<br>
<br>
<br>
> > The other part that I am still missing is replacment for<br>
> > LLVMCreateGDBRegistrationListener();<br>
> > LLVMCreatePerfJITEventListener();<br>
> > LLVMOrcRegisterJITEventListener(llvm_opt0_orc, l);<br>
> > I haven't yet looked at whether there is replacement infrastructure for<br>
> > this already. Is there?  Will look after the next few meetings...<br>
<br>
> You can continue to use LLVMCreateGDBRegistrationListener and<br>
> LLVMCreatePerfJITEventListener from ExecutionEngine.h for now. We just need<br>
> to add an OrcV2 equivalent of LLVMOrcRegisterJITEventListener. I'll do that<br>
> today.<br>
<br>
Cool.<br>
<br>
Greetings,<br>
<br>
Andres Freund<br>
</blockquote></div>