search

stephenrkell / libdlbind

Dynamic creation and update of ELF files, or: an allocator for JIT compilers
32 stars 1 forks source link

Cleanup issues #1

Open stephenrkell opened 11 months ago

stephenrkell commented 11 months ago

Currently we leave temporary shared objects lying around the filesystem, which is not good.

If they were POSIX shared-memory objects, the cleanup semantics might be different/nicer and a pathname might still be available for the debugger to use... need to check.

The other option is to unlink the file and rely on Linux's magic /proc/self/fd symlinks: we can still open a deleted file that way. But we would need to make the program's link map embed the /proc/NNN/fd/MMM link and check that gdb can still grok this.

stephenrkell commented 11 months ago

Predictably, POSIX shared memory is no better: shm_unlink() needs to be called.

stephenrkell commented 9 months ago

Maybe dlopening via the proc symlink is the right answer? Currently we close the file descriptor before we dlopen, even. This way we would have to hang on to it. How long for? At first it might seem we only have to hang on to it until we've dlopened it. But that's not true... if we want to be able to re-dlopen it later using the /proc/MMM/fd/N link (note: not /proc/self/fd/N, because we need to use a path that a debugger can also use), we need N to remain valid. So we'd have to hang on to the fd... until the corresponding dldelete(), which is a real call. (What we're really trying to do is make cleanup happen naturally at process exit, even if the client does not call dldelete().)

The good news is that we don't have to remember the fd anywhere... although it's nasty, we can snarf it from the path and use atoi() on it.

I think this approach works, although it is very Linux-specific.

stephenrkell commented 9 months ago

I've now implemented a rough version of this in 1c80375. Will leave this issue open until I have more confidence that it works. Reinstating dldelete() seems necessary also.

stephenrkell commented 9 months ago

Being optimistic for a second, non-Linux systems may have other interfaces for creating named temporary files that don't outlive the creating process....