https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64206
David Malcolm <dmalcolm at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2014-12-06
Ever confirmed|0 |1
--- Comment #1 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
(In reply to [email protected] from comment #0)
> Some users of the DSO created by the JIT (probably mostly debuggers) might
> have a hard time getting to the file before it gets unlinked. For some gdb
> versions, for instance, this is fatal. Try gdb 7.8.1, for instance, see
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1170861
>
> That is certainly gdb's fault but it's an example about the type of problems
> that can appear.
For reference, this works for me with:
gdb-7.6.50.20130731-19.fc20.x86_64
> It certainly is useful to unlink the file as quickly as possible so that in
> case of a problem crash nothing is left behind. But there at least should
> be the possibility to prevent the early unlink. Dave suggested to tie this
> to the enabling of debuginfo generation in libgccjit. I'm actually not
> entirely sure that's the best possibility since even without debuginfo the
> debugger can use the ELF symbols to place breakpoints etc. Maybe a boolean
> option?
>
> As a solution it should be quite easy to transfer ownership of the file and
> directory from playback::context to result.
I'm working on a patch that supports delaying the cleanup of the tempdir, with
the cleanup normally occurring at the end of the compile, after the .so has
been dlopened, but deferring it to when gcc_jit_result_release occurs if the
user set GCC_JIT_BOOL_OPTION_DEBUGINFO.
FWIW I think of this flag as a
"make debugging work please, I'm willing to take a performance hit"
request by the user, rather than specifically for the generation of debuginfo.
I want to avoid a proliferation of lots of options that need to be enabled,
since this makes the library more difficult to use. Obviously a tradeoff
though. (Maybe that flag should be renamed?)
