[llvm-dev] Clang/LLVM JIT - When to use "registerEHFrames()"

Jameson Nash via llvm-dev llvm-dev at lists.llvm.org
Wed Oct 18 15:03:27 PDT 2017


> So... there is no way to make throw and catch working in a jitted code
> under Windows?
>

I have used throw and catch in jitted code, so "no way" is too strong. But
there's a large range of possible states between "no way" and "always
enabled OOTB". Currently, this is pretty close to the "mostly
unimplemented" side of the spectrum in LLVM.

Also - to get rid of reallocation problems, it's no help to compile to .elf
> files?
>

I never dug through the spec fully, but if I remember correctly, ELF does
not support the relocation type that is required by the Windows unwind
table specification (specifically, 32-bit image-base relative). So yes,
this would get rid of relocation problems. But it might then be tricky to
build the unwind information. (Perhaps this wouldn't be feasible in a
static environment, but it's possible in a JIT environment, since this is
indeed how it's done in JuliaLang).


>
> From:        Jameson Nash <vtjnash at gmail.com>
> To:        Hayden Livingston <halivingston at gmail.com>,
> bjoern.gaier at horiba.com
> Cc:        LLVM Developers Mailing List <llvm-dev at lists.llvm.org>, Stefan
> Gränitz <stefan.graenitz at gmail.com>
> Date:        16.10.2017 23:04
> Subject:        Re: [llvm-dev] Clang/LLVM JIT - When to use
> "registerEHFrames()"
> ------------------------------
>
>
>
> Historically? I implemented support for exceptions back in LLVM 3.3,
> before LLVM had an implementation of a Windows unwinder.
>
> Currently? As recent as LLVM 4.0, I don't think the JIT was fully capable
> of handling COFF files, and LLVM wouldn't emit the correct sections (with
> the COFF-formatted unwind tables) when used in ELF mode.
>
> The prolog is known to be standard since Julia disables FPO on all code,
> so the hand-coded values simply needed to declare that to the unwinder.
> Windows doesn't have epilog records (it instead infers them from the
> structure of the assembly itself, and requires that LLVM only generate
> function returns using a particular finite set of instructions), so that
> has to be handled elsewhere during machine code selection/emission.
>
>
> On Tue, Oct 10, 2017 at 11:07 AM Hayden Livingston <
> *halivingston at gmail.com* <halivingston at gmail.com>> wrote:
> Julia is a language, and you can use their code.
>
> Jameson Nash, could you please let us know why Julia's code has hard
> coded values for the unwinding? Is your prolog/epilog some standard
> one?
>
> On Fri, Oct 6, 2017 at 2:47 AM,  <*bjoern.gaier at horiba.com*
> <bjoern.gaier at horiba.com>> wrote:
> > Hello everyone,
> >
> > I was following the discussion, but I have to admit, that my skills
> aren't
> > high enough to follow you guys. For my current exception problem, I don't
> > have to stick around with the PECOFF format, so I used clang to don't
> > compile to a PECOFF, but to a ELF file. Interesting, now I'm missing the
> > functions:
> > __cxa_allocate_exception
> > __cxa_throw
> > _ZTI
> >
> > I loaded the DLL "libstdc++.dll" and found all of the addresses - but the
> > application still crashes when the exception is thrown.
> >
> > So... Do you think, that "Julias Code" could help me? You mentioned her
> in
> > one of the mails, but I don't know her - or her code.
> >
> > Also, is it a better idea to compile all dynamic code to the ELF format,
> > because PECOFF isn't fully supported?
> >
> > 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/llvm-dev/attachments/20171018/1a00e4a3/attachment.html>


More information about the llvm-dev mailing list