Re: [Tinycc-devel] Win64 PE JIT codegen: Bad unwind info / runtime function tables

[Janus Lynggaard Thorborg]

Okay, so if I apply that on top of the other patch, everything seems to work! I have only tested for running code JIT'ed to memory. Given a stack trace such as this:

4. C++ API
3. N frames from a compiled string in TCC
2. K frames from a TCC object file from another context, but loaded into the same as above
1. C++ API

It is possible and well defined to:
a) longjmp from #4 to #1
b) catch a hardware exception using SEH in #1 from #2, #3 and #4
c) throw a C++ exception in #4 and catch it in #1

Thanks a lot, I really appreciate it!

2017-11-08 18:42 GMT+01:00 grischka <address@hidden>:

Janus Lynggaard Thorborg wrote:

Okay, so I thought everything was good, but it turns out one of the real
issues was adding mixing object files and compilations into one tcc state,
something my unit tests didn't cover. So here's a dump of the
RUNTIME_FUNCTION array passed to RtlAddFunctionTable, where I compiled some
stuff using *tcc_compile_string* and *tcc_add_file("someobject.o")*:
[...]
As can be seen, from runtime function 14, the function entries start to
overlap again. Probably, there's a missing segment/section offset somewhere
when TCC adds runtime functions from different contexts/sections/object
files?

Yes, I already wondered how it can work if for file output (exe/dll)
we handle R_XXX_RELATIVE in pe_relocate_rva() but don't do anything
like that for -run.  Not surprisingly it doesn't work.

Attached is a patch to correct this.  It removes pe_relocate_rva()
altogether and instead handles R_XXX_RELATIVE in the relocate backends
(as it should be).

It also sets the uw_pdata section in case it was not set by any
compilation, that is if you wanted to run just already compiled
object files.

If it works I'll push that later.

--- grischka


_______________________________________________
Tinycc-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/tinycc-devel