Hi Daniel,
that looks very interesting. I think it'll take some time to understand
what's going on, but I already got some good parts. And even if I won't
end up using it, this seems like a good way to learn some stuff. So
thanks a lot!
For now I don't need the full power, so I think I'll take what I learned
here and stick to a simple, hacky solution along the lines of Brandon's
suggestions. Like enumerating object files in some specified directory,
then mapping
readCreateProcessWithExitCode (shell $ "readelf --symbols --wide " ++ path ++ " | grep
closure | tr --squeeze-repeat ' ' | cut --delimiter=' ' --fields=9") ""
over them and z-encoding back and forth to discover what the heck I'm
actually loading.
Elegant? No. Secure? No. Portable? …sufficiently. Works? …hopefully.
I got the feeling there is no good non-hacky way. Somewhere there's
always some extra c code or something. I'm just glad my current goal is
to just load object files, not compile user-supplied "scripts" into a
running project or something.
So thanks again to you all!
Cheers,
MarLinn
On 2017-10-15 02:30, Daniel Gröber wrote:
Hi,
I think you might be interrested in my rts-loader package,
particularly the [mkSymbol
function](https://github.com/DanielG/rts-loader/blob/master/System/Loader/RTS.hs#L275).
It should demonstrate how you can construct the symbol names for
dynamic loading and how to coax the information needed out of Cabal,
see the README and the rest of the source.
--Daniel
On Sat, Oct 14, 2017 at 09:59:03PM +0200, MarLinn wrote:
That sounds reasonable, but also like there *can not be* a way to obtain
that hash at runtime. And therefore, no way to discover the true package
name.
Which in turn makes discovery and loading of plug-ins a bit harder. Well, I
guess it's for a good reason so I'll have to work around it. Good to know.
Thanks for helping out!
Cheers,
MarLinn
On 2017-10-14 20:11, Brandon Allbery wrote:
On Sat, Oct 14, 2017 at 12:48 PM, MarLinn <monkle...@gmail.com
<mailto:monkle...@gmail.com>> wrote:
So the "actual" package name seems to be
"Plugin-0.0.0.0-2QaFQQzYhnKJSPRXA7VtPe".
That leaves the random(?) characters behind the version number to
be explained.
ABI hash of that specific package build, which is needed because
compiling with different optimization levels etc. will change what part
of the internals gets exposed in the .hi file for inlining into other
modules; mismatches there lead to *really* weird behavior. (If you're
lucky, it'll "just" be a type mismatch in code you didn't write, because
it came from the .hi file. If unlucky, it compiles but dumps core at
runtime.)
--
brandon s allbery kf8nh sine nomine associates
allber...@gmail.com <mailto:allber...@gmail.com> ballb...@sinenomine.net
<mailto:ballb...@sinenomine.net>
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
