https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64206
drepper.fsp+rhbz at gmail dot com <drepper.fsp+rhbz at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |---
--- Comment #8 from drepper.fsp+rhbz at gmail dot com <drepper.fsp+rhbz at
gmail dot com> ---
(In reply to David Malcolm from comment #5)
> Does this fix the symptoms you're seeing?
Sorry for the delay, I'm terribly behind.
I just tried it and I don't see any improvement. This is on Fedora 21 with a
mainline gcc. By the call to the loaded function is made the entire directory
the jit uses is gone. This is before the call to gcc_jit_results_release.
Since I don't have a fixed gdb (or more correct: BFD) I still see the gdb
crash.
I haven't looked at the logic of your patch. From my perspective the right
solution is still to enable, on request, to delay removing all the files until
the call to gcc_jit_result_release. There is already this interface available,
let's use it for one more thing. For production runs we probably want the
current behavior.
I don't think you need any code to reproduce, I see the problem with a trivial
hello world like the one below. Just put a breakpoint on line 55 (the call to
some_fn) and step into the function. I immediately get
Can't read data for section '.eh_frame' in file '/tmp/libgccjit-a07Nh7/fake.so'
and upon issuing p $pc gdb will crash (gdb 7.8.2-38.fc21).
