llvm dev - Sep 2017 - Clang/LLVM JIT - When to use "registerEHFrames()"

Hello Stefan,

I'm happy someone replied to my problem! Many thanks! To be honest... I 
didn't understood much of your mail. I'm a beginner with the JIT - so I 
will explain what I've done.

To manage the memory and resolve symbols, I'm using my own Resolver-Class, 
which overloads the allocation and the findSymbol functions. I've noticed 
today, that the "registerEHFrames" function of my class gets called 
automatically, with correct values. I'm remapping my code and the address 
are still correct. Great! But, what should I do with it? I pass the values 
to the original function, but my exception won't be caught! It's an 
exception raised inside the JITTED code and should also catched there.

I tried loading the "msvcrt.lib" as a archive. That was... a bad idea!
I
get a Exception while loading:
Assertion failed: ((int64_t)Result <= INT32_MAX) && "Relocation
overflow",
file \lib\executionengine\runtimedyld\Targets/RuntimeDyldCOFFX86_64.h, 
line 81

Research didn't helped me! My code was compiled with /MD, but it didn't 
changed. So I'm still stupid D:
The JITTED code must be loaded to shared memory later - there aren't 
libraries, so even if this would work, it wouldn't help me. I tried 
compiling my code with sjlj-exceptions. Didn't worked...

Is there no hope left?

Kind regards
Björn



From:   Stefan Gränitz <stefan.graenitz at gmail.com>
To:     bjoern.gaier at horiba.com, llvm-dev at lists.llvm.org
Date:   27.09.2017 23:09
Subject:        Re: [llvm-dev] Clang/LLVM JIT - When to use 
"registerEHFrames()"



Hi Björn

To first answer your questionin the subject: For x86 registerEHFrames() is 
only a stub. For x86_64 registerEHFrames() is implemented properly in 
RuntimeDyldCOFFX86_64, calling MemMgr.registerEHFrames() for each EH frame 
section. It should be called and work out of the box without your 
involvement, but unfortunately it won't solve your issue. All the 
essential information is there in the comments, just check the base 
classes.

This thread from last year helps with your unresolved symbol:
http://lists.llvm.org/pipermail/llvm-dev/2016-October/106458.html

Back then I tried to solve a related issue: SEH exceptions thrown from 
code loaded with RuntimeDyld had to be caught in statically compiled code. 
It turned out Windows explicitly prohibits this. I got in touch with 
Microsoft people and IIRC it's due to security concerns.

Depending on your specific case, you may want to fall back to vectored 
exception handling. In my experience this was a dead end though. If you 
need a solution for arbitrary situations, you just can't jump back to a 
"safe" place to continue execution. I tried setjump (on each entry
point
to the dynamically loaded code) / longjmp (in the vectored exception 
handler), but the address was invalidated when I accessed it. I suspect 
it's kind of undefined behavior to call longjmp outside a child frame of 
the function that called setjmp. Anyway it turned all far too hacky.

If you are willing to do research, compare implementations and behavior 
with the MachO and ELF versions. At least one of them works, just not on 
Windows ;)
Also check the LLILC project: https://github.com/dotnet/llilc I heard 
about some solution that uses trampolines to push exceptions back to 
dynamically loaded code and handle them there.

AND disclaimer: I did not follow recent developments in this area. If 
there's news please let me know!

Cheers & Good Luck!
Stefan
Am 25.09.17 um 11:31 schrieb via llvm-dev:
Hello friendly LLVM-World, 

because I don't know if I had send my problem to the correct Mailing-List, 
I will send my problem to this address too. I'm not subscribed to this 
list, so please add my in CC if you response. 

Kind regards 
Björn 


From:        Bjoern Gaier/HE/HORIBA 
To:        Clang Dev <cfe-dev at lists.llvm.org>, "cfe-dev" 
<cfe-dev-bounces at lists.llvm.org> 
Date:        19.09.2017 08:05 
Subject:        Clang/LLVM JIT - When to use "registerEHFrames()" 


Hello friendly Clang-World, 

I was experimenting with Clang and the JIT capabilities of LLVM. Most of 
my attempts were successfully but, I still fail miserably at exceptions. 
Doing research I found the function "registerEHFrames()" which should 
assist me supporting exceptions - but sadly the documentation I found 
wasn't helpful. 
I looked at into the "notifyObjectLoaded" function and discovered that
there appear some symbol names starting with "$" - I expected them to
be
connected to my try and catch block. But what now? As usually, at this 
point I have there names, but can't get there address to register them 
with the "registerEHFrames()" function. Also the JITTER still wants an
address for "??_7type_info@@6B@" which is the virtual table of the 
type_info struct. 

Confusing! So friendly Clang-World, could you please help? 

Not so important - but has the dragon which decorates clang and LLVM a 
name? 

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. 

_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-- 
https://weliveindetail.github.io/blog/
https://cryptup.org/pub/stefan.graenitz at gmail.com


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/llvm-dev/attachments/20170928/5856f975/attachment.html>

> I tried loading the "msvcrt.lib" as a archive. That was... a bad
idea!
> I get a Exception while loading:
> Assertion failed: ((int64_t)Result <= INT32_MAX) &&
"Relocation
> overflow", file
> \lib\executionengine\runtimedyld\Targets/RuntimeDyldCOFFX86_64.h, line 81
It's a limitation of the COFF/PE format and unrelated to exceptions.
This patch explains it and shows a workaround:
https://github.com/weliveindetail/pj-llvm/commit/97cd336d458ae9c73232d1b539ceefcdb2f5eb0f
> Is there no hope left?
Well at least I am not aware of a solution.

Am 28.09.17 um 16:04 schrieb bjoern.gaier at horiba.com:
> Hello Stefan,
>
> I'm happy someone replied to my problem! Many thanks! To be honest...
> I didn't understood much of your mail. I'm a beginner with the JIT
-
> so I will explain what I've done.
>
> To manage the memory and resolve symbols, I'm using my own
> Resolver-Class, which overloads the allocation and the findSymbol
> functions. I've noticed today, that the "registerEHFrames"
function of
> my class gets called automatically, with correct values. I'm remapping
> my code and the address are still correct. Great! But, what should I
> do with it? I pass the values to the original function, but my
> exception won't be caught! It's an exception raised inside the
JITTED
> code and should also catched there.
>
> I tried loading the "msvcrt.lib" as a archive. That was... a bad
idea!
> I get a Exception while loading:
> Assertion failed: ((int64_t)Result <= INT32_MAX) &&
"Relocation
> overflow", file
> \lib\executionengine\runtimedyld\Targets/RuntimeDyldCOFFX86_64.h, line 81
>
> Research didn't helped me! My code was compiled with /MD, but it
> didn't changed. So I'm still stupid D:
> The JITTED code must be loaded to shared memory later - there aren't
> libraries, so even if this would work, it wouldn't help me. I tried
> compiling my code with sjlj-exceptions. Didn't worked...
>
> Is there no hope left?
>
> Kind regards
> Björn
>
>
>
> From:        Stefan Gränitz <stefan.graenitz at gmail.com>
> To:        bjoern.gaier at horiba.com, llvm-dev at lists.llvm.org
> Date:        27.09.2017 23:09
> Subject:        Re: [llvm-dev] Clang/LLVM JIT - When to use
> "registerEHFrames()"
> ------------------------------------------------------------------------
>
>
>
> Hi Björn
>
> To first answer your questionin the subject: For x86
> registerEHFrames() is only a stub. For x86_64 registerEHFrames() is
> implemented properly in RuntimeDyldCOFFX86_64, calling
> MemMgr.registerEHFrames() for each EH frame section. It should be
> called and work out of the box without your involvement, but
> unfortunately it won't solve your issue. All the essential information
> is there in the comments, just check the base classes.
>
> This thread from last year helps with your unresolved symbol:_
> __http://lists.llvm.org/pipermail/llvm-dev/2016-October/106458.html_
>
> Back then I tried to solve a related issue: SEH exceptions thrown from
> code loaded with RuntimeDyld had to be caught in statically compiled
> code. It turned out Windows explicitly prohibits this. I got in touch
> with Microsoft people and IIRC it's due to security concerns.
>
> Depending on your specific case, you may want to fall back to vectored
> exception handling. In my experience this was a dead end though. If
> you need a solution for arbitrary situations, you just can't jump back
> to a "safe" place to continue execution. I tried setjump (on each
> entry point to the dynamically loaded code) / longjmp (in the vectored
> exception handler), but the address was invalidated when I accessed
> it. I suspect it's kind of undefined behavior to call longjmp outside
> a child frame of the function that called setjmp. Anyway it turned all
> far too hacky.
>
> If you are willing to do research, compare implementations and
> behavior with the MachO and ELF versions. At least one of them works,
> just not on Windows ;)
> Also check the LLILC project: _https://github.com/dotnet/llilc_I heard
> about some solution that uses trampolines to push exceptions back to
> dynamically loaded code and handle them there.
>
> AND disclaimer: I did not follow recent developments in this area. If
> there's news please let me know!
>
> Cheers & Good Luck!
> Stefan
>
> Am 25.09.17 um 11:31 schrieb via llvm-dev:
> Hello friendly LLVM-World,
>
> because I don't know if I had send my problem to the correct
> Mailing-List, I will send my problem to this address too. I'm not
> subscribed to this list, so please add my in CC if you response.
>
> Kind regards
> Björn
>
>
> From:        Bjoern Gaier/HE/HORIBA
> To:        Clang Dev _<cfe-dev at lists.llvm.org>_
> <mailto:cfe-dev at lists.llvm.org>, "cfe-dev"
> _<cfe-dev-bounces at lists.llvm.org>_ <mailto:cfe-dev-bounces at
lists.llvm.org>
> Date:        19.09.2017 08:05
> Subject:        Clang/LLVM JIT - When to use "registerEHFrames()"
>
> ------------------------------------------------------------------------
>
>
> Hello friendly Clang-World,
>
> I was experimenting with Clang and the JIT capabilities of LLVM. Most
> of my attempts were successfully but, I still fail miserably at
> exceptions. Doing research I found the function
"registerEHFrames()"
> which should assist me supporting exceptions - but sadly the
> documentation I found wasn't helpful.
> I looked at into the "notifyObjectLoaded" function and discovered
that
> there appear some symbol names starting with "$" - I expected
them to
> be connected to my try and catch block. But what now? As usually, at
> this point I have there names, but can't get there address to register
> them with the "registerEHFrames()" function. Also the JITTER
still
> wants an address for "??_7type_info@@6B@" which is the virtual
table
> of the type_info struct.
>
> Confusing! So friendly Clang-World, could you please help?
>
> Not so important - but has the dragon which decorates clang and LLVM a
> name?
>
> 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.
>
> _______________________________________________
> LLVM Developers mailing list
> _llvm-dev at lists.llvm.org_ <mailto:llvm-dev at lists.llvm.org>
> _http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev_
>
> -- 
> _https://weliveindetail.github.io/blog/_
> _https://cryptup.org/pub/stefan.graenitz at gmail.com_
>
>
> 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. 
-- 
https://weliveindetail.github.io/blog/
https://cryptup.org/pub/stefan.graenitz at gmail.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170928/77a0f503/attachment.html>

Hi Bjoern,

I'm trying to make exceptions run. I have an Object file with a
function,
> throwing a 1 and a second function which should catch the 1. Normal JITTING
> under Windows showed me, that I have an unresolved reference to the virtual
> table of type_info. Some experiments later I was able to load
"msvcrt.lib"
> as an archive and could resolve the reference. Nice - but than
> "??_Etype_info@@UEAPEAXI at Z" was missing too. Ufff! I decided
to ignore
> this. Because, when I try to load every .lib and .obj provided by Visual
> Studio, I get an assertion failure with "Relocation type not
implemented
> yet!".

RuntimeDyldCOFF is missing a lot of relocation support. We need a COFF
expert to fix that and unfortunately I'm not one.

I decided to have a look at "_CxxThrowException". I inserted my
own
> function for the JIT and had a look at the parameters. I got two of them.
> The first was the address of the Exception-Object, which was correct. The
> second is the address for the "_ThrowInfo". This address was
valid too, but
> all its members - except from attributes - are null. So I can't throw
this
> Exception. I tried to pass the address of typeid(1) to it, or modificate
> the call. Nothing helped.

I don't know windows exception handling well, but if it's anything like
DWARF EH then I'd be inclined to blame the missing relocations/fixups --
the _ThrowInfo struct (or whatever data-source ultimately populates it)
probably isn't being fixed up.

I have no clue and no idea anymore. So... Do you have an idea?


I'm afraid I don't personally. We need some windows linker / system
experts
to take an interest in the JIT.

Back then I tried to solve a related issue: SEH exceptions thrown from
code
> loaded with RuntimeDyld had to be caught in statically compiled code. It
> turned out Windows explicitly prohibits this. I got in touch with Microsoft
> people and IIRC it's due to security concerns.

Stefan -- That's an interesting restriction. :/
Does it prohibit exceptions thrown in JIT'd code from being caught also in
JIT'd code, or does it only apply if an exception crosses the boundary back
into statically compiled code?
Do you know how they were enforcing that?

Cheers,
Lang.





On Thu, Sep 28, 2017 at 12:37 PM, Stefan Gränitz via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> I tried loading the "msvcrt.lib" as a archive. That was... a bad
idea! I
> get a Exception while loading:
> Assertion failed: ((int64_t)Result <= INT32_MAX) &&
"Relocation overflow",
> file \lib\executionengine\runtimedyld\Targets/RuntimeDyldCOFFX86_64.h,
> line 81
>
> It's a limitation of the COFF/PE format and unrelated to exceptions.
This
> patch explains it and shows a workaround:
> https://github.com/weliveindetail/pj-llvm/commit/
> 97cd336d458ae9c73232d1b539ceefcdb2f5eb0f
>
> Is there no hope left?
>
> Well at least I am not aware of a solution.
>
> Am 28.09.17 um 16:04 schrieb bjoern.gaier at horiba.com:
>
> Hello Stefan,
>
> I'm happy someone replied to my problem! Many thanks! To be honest... I
> didn't understood much of your mail. I'm a beginner with the JIT -
so I
> will explain what I've done.
>
> To manage the memory and resolve symbols, I'm using my own
Resolver-Class,
> which overloads the allocation and the findSymbol functions. I've
noticed
> today, that the "registerEHFrames" function of my class gets
called
> automatically, with correct values. I'm remapping my code and the
address
> are still correct. Great! But, what should I do with it? I pass the values
> to the original function, but my exception won't be caught! It's an
> exception raised inside the JITTED code and should also catched there.
>
> I tried loading the "msvcrt.lib" as a archive. That was... a bad
idea! I
> get a Exception while loading:
> Assertion failed: ((int64_t)Result <= INT32_MAX) &&
"Relocation overflow",
> file \lib\executionengine\runtimedyld\Targets/RuntimeDyldCOFFX86_64.h,
> line 81
>
> Research didn't helped me! My code was compiled with /MD, but it
didn't
> changed. So I'm still stupid D:
> The JITTED code must be loaded to shared memory later - there aren't
> libraries, so even if this would work, it wouldn't help me. I tried
> compiling my code with sjlj-exceptions. Didn't worked...
>
> Is there no hope left?
>
> Kind regards
> Björn
>
>
>
> From:        Stefan Gränitz <stefan.graenitz at gmail.com>
> <stefan.graenitz at gmail.com>
> To:        bjoern.gaier at horiba.com, llvm-dev at lists.llvm.org
> Date:        27.09.2017 23:09
> Subject:        Re: [llvm-dev] Clang/LLVM JIT - When to use
> "registerEHFrames()"
> ------------------------------
>
>
>
> Hi Björn
>
> To first answer your questionin the subject: For x86 registerEHFrames() is
> only a stub. For x86_64 registerEHFrames() is implemented properly in
> RuntimeDyldCOFFX86_64, calling MemMgr.registerEHFrames() for each EH frame
> section. It should be called and work out of the box without your
> involvement, but unfortunately it won't solve your issue. All the
essential
> information is there in the comments, just check the base classes.
>
> This thread from last year helps with your unresolved symbol:
> *http://lists.llvm.org/pipermail/llvm-dev/2016-October/106458.html*
> <http://lists.llvm.org/pipermail/llvm-dev/2016-October/106458.html>
>
> Back then I tried to solve a related issue: SEH exceptions thrown from
> code loaded with RuntimeDyld had to be caught in statically compiled code.
> It turned out Windows explicitly prohibits this. I got in touch with
> Microsoft people and IIRC it's due to security concerns.
>
> Depending on your specific case, you may want to fall back to vectored
> exception handling. In my experience this was a dead end though. If you
> need a solution for arbitrary situations, you just can't jump back to a
> "safe" place to continue execution. I tried setjump (on each
entry point to
> the dynamically loaded code) / longjmp (in the vectored exception handler),
> but the address was invalidated when I accessed it. I suspect it's kind
of
> undefined behavior to call longjmp outside a child frame of the function
> that called setjmp. Anyway it turned all far too hacky.
>
> If you are willing to do research, compare implementations and behavior
> with the MachO and ELF versions. At least one of them works, just not on
> Windows ;)
> Also check the LLILC project: *https://github.com/dotnet/llilc*
> <https://github.com/dotnet/llilc> I heard about some solution that
uses
> trampolines to push exceptions back to dynamically loaded code and handle
> them there.
>
> AND disclaimer: I did not follow recent developments in this area. If
> there's news please let me know!
>
> Cheers & Good Luck!
> Stefan
>
> Am 25.09.17 um 11:31 schrieb via llvm-dev:
> Hello friendly LLVM-World,
>
> because I don't know if I had send my problem to the correct
Mailing-List,
> I will send my problem to this address too. I'm not subscribed to this
> list, so please add my in CC if you response.
>
> Kind regards
> Björn
>
>
> From:        Bjoern Gaier/HE/HORIBA
> To:        Clang Dev *<cfe-dev at lists.llvm.org>* <cfe-dev at
lists.llvm.org>,
> "cfe-dev" *<cfe-dev-bounces at lists.llvm.org>*
> <cfe-dev-bounces at lists.llvm.org>
> Date:        19.09.2017 08:05
> Subject:        Clang/LLVM JIT - When to use "registerEHFrames()"
> ------------------------------
>
>
> Hello friendly Clang-World,
>
> I was experimenting with Clang and the JIT capabilities of LLVM. Most of
> my attempts were successfully but, I still fail miserably at exceptions.
> Doing research I found the function "registerEHFrames()" which
should
> assist me supporting exceptions - but sadly the documentation I found
> wasn't helpful.
> I looked at into the "notifyObjectLoaded" function and discovered
that
> there appear some symbol names starting with "$" - I expected
them to be
> connected to my try and catch block. But what now? As usually, at this
> point I have there names, but can't get there address to register them
with
> the "registerEHFrames()" function. Also the JITTER still wants an
address
> for "??_7type_info@@6B@" which is the virtual table of the
type_info
> struct.
>
> Confusing! So friendly Clang-World, could you please help?
>
> Not so important - but has the dragon which decorates clang and LLVM a
> name?
>
> 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.
>
> _______________________________________________
> LLVM Developers mailing list
> *llvm-dev at lists.llvm.org* <llvm-dev at lists.llvm.org>
> *http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev*
> <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>
> --
> *https://weliveindetail.github.io/blog/*
> <https://weliveindetail.github.io/blog/>
> *https://cryptup.org/pub/stefan.graenitz at gmail.com*
> <https://cryptup.org/pub/stefan.graenitz at gmail.com>
>
>
> 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.
>
>
> --
https://weliveindetail.github.io/blog/https://cryptup.org/pub/stefan.graenitz at
gmail.com
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170929/00a957eb/attachment.html>