Re: Can I get the internal name of a package at runtime?

[Daniel Gröber]

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  > > 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  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


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC HEAD now needs extra tools to build libffi?

[Ben Gamari]

Joachim Breitner  writes:

> Hi,
>
>
> Am Dienstag, den 03.10.2017, 13:55 -0400 schrieb Thomas Jakway:
>> Anyone else getting linker errors?
>> 
>> /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>> 20171003.so: error: undefined reference to 'ffi_type_uint64'
>> chmod +x 
>> inplace/bin/runghc
>> /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>> 20171003.so: error: undefined reference to 'ffi_type_uint32'
>
> …
>
> I can confirm these. Looks like perf.haskell.org is stuck on that
> problem.
>
Very odd. I don't understand why I'm not seeing this myself. Does
reverting e462b657daa003d365440afdad14c5756898b5e0 and
e515c7f37be97e1c2ccc497ddd0a730e63ddfa82 allow things to build?

If so I say we revert until we can figure out what is going on.

Cheers,

- Ben


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC HEAD now needs extra tools to build libffi?

[Joachim Breitner]

Hi,


Am Dienstag, den 03.10.2017, 13:55 -0400 schrieb Thomas Jakway:
> Anyone else getting linker errors?
> 
> /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
> 20171003.so: error: undefined reference to 'ffi_type_uint64'
> chmod +x 
> inplace/bin/runghc
> /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
> 20171003.so: error: undefined reference to 'ffi_type_uint32'

…

I can confirm these. Looks like perf.haskell.org is stuck on that
problem.


Thomas, did you resolve that issue?

Joachim

-- 
Joachim Breitner
  m...@joachim-breitner.de
  http://www.joachim-breitner.de/


signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Can I get the internal name of a package at runtime?

[Brandon Allbery]

Oh, wait, that won;t work because you're trying to find the name of
something to load at runtime. But you can still z-encode the known parts of
the name and look for files starting and ending with those components; the
ABI hash won't matter because a dynamically loaded plugin can't use the
inlinings from the .hi file anyway. If you get multiple matches, you could
warn about it but because you can't use the .hi inlinings in that context
it won't matter which one you load.

On Sat, Oct 14, 2017 at 4:19 PM, Brandon Allbery 
wrote:

> On Sat, Oct 14, 2017 at 3:59 PM, 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.
>>
>
> I can think of a hacky way: make sure the symbol table is still present in
> the executable and that you can find said executable, z-encode the part of
> the package+version you know and a symbol you know, and look for symbols
> that start with one and end with the other; the hash will be in between.
>
> --
> brandon s allbery kf8nh   sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>



-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Can I get the internal name of a package at runtime?

[Brandon Allbery]

On Sat, Oct 14, 2017 at 3:59 PM, 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.
>

I can think of a hacky way: make sure the symbol table is still present in
the executable and that you can find said executable, z-encode the part of
the package+version you know and a symbol you know, and look for symbols
that start with one and end with the other; the hash will be in between.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Can I get the internal name of a package at runtime?

[MarLinn]

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 > 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  
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

Re: Can I get the internal name of a package at runtime?

[Brandon Allbery]

On Sat, Oct 14, 2017 at 12:48 PM, MarLinn  wrote:

> So the "actual" package name seems to be "Plugin-0.0.0.0-2QaFQQzYhnKJSP
> RXA7VtPe".
> 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  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Can I get the internal name of a package at runtime?

[MarLinn]

Hi Edward,

thank you.
That knowledge revealed that the "Ozi" part was actually the version number.

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.
But at least now I can exploit the fact that a 
"libHSPlugin-0.0.0.0-2QaFQQzYhnKJSPRXA7VtPe.a" file is generated. So if 
I don't find the complete answer I still have a more portable way for 
discovery than inspecting headers.


That's quite useful.

Cheers,
MarLinn


On 2017-10-14 18:01, Edward Z. Yang wrote:

Hi MarLinn,

The mangling name is "z-encoded".  It is documented here:
https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/SymbolNames

Edward

Excerpts from MarLinn's message of 2017-10-14 17:35:28 +0200:

Hi.

I'm experimenting with plug-ins right now. I did manage to dynamically
load functions at runtime. The caveat: Something (cabal? ghc?) mangles
the package names. For example, to load a function called "theFunction"
from a module called "Callee" in a package "Plugin", I had to address it
via the name
"Pluginzm0zi0zi0zi0zm2QaFQQzzYhnKJSPRXA7VtPe_Callee_theFunction_closure".
O…K. Most parts of that are clear, and thanks for making my package
cooler by appending a "z", but who is this Ozi guy and why is he rapping
about modems? Without knowing Ozi, the only way I found to get at this
magic string is to manually look at the actual ELF-header of the
compiled module. While that might be a robust way, it seems neither
portable nor elegant.

The "plugins" library failed too, probably for the same reason. (Or it's
under-documented. Probably both.) The "dynamic-loader" library does
something via c, therefore no.

Which brings me to the question: Is there any way for a module to get at
its own internal package name? Or even at the internal name of an
external package? If not, can I somehow recreate the magic mangling at
runtime? At first I thought the functions in the "Module", "Name" etc
modules of GHC might help – but it seems I either need an existing Name
(that I have no idea how to get) or I have to create one (with no idea
what magic mangler to call).

I'm asking this question here rather than on café as I feel that if
there is a solution, it's probably buried in the details of GHC.

Thanks for any suggestions,
MarLinn



___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Can I get the internal name of a package at runtime?

[Edward Z. Yang]

Hi MarLinn,

The mangling name is "z-encoded".  It is documented here:
https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/SymbolNames

Edward

Excerpts from MarLinn's message of 2017-10-14 17:35:28 +0200:
> Hi.
> 
> I'm experimenting with plug-ins right now. I did manage to dynamically 
> load functions at runtime. The caveat: Something (cabal? ghc?) mangles 
> the package names. For example, to load a function called "theFunction" 
> from a module called "Callee" in a package "Plugin", I had to address it 
> via the name 
> "Pluginzm0zi0zi0zi0zm2QaFQQzzYhnKJSPRXA7VtPe_Callee_theFunction_closure". 
> O…K. Most parts of that are clear, and thanks for making my package 
> cooler by appending a "z", but who is this Ozi guy and why is he rapping 
> about modems? Without knowing Ozi, the only way I found to get at this 
> magic string is to manually look at the actual ELF-header of the 
> compiled module. While that might be a robust way, it seems neither 
> portable nor elegant.
> 
> The "plugins" library failed too, probably for the same reason. (Or it's 
> under-documented. Probably both.) The "dynamic-loader" library does 
> something via c, therefore no.
> 
> Which brings me to the question: Is there any way for a module to get at 
> its own internal package name? Or even at the internal name of an 
> external package? If not, can I somehow recreate the magic mangling at 
> runtime? At first I thought the functions in the "Module", "Name" etc 
> modules of GHC might help – but it seems I either need an existing Name 
> (that I have no idea how to get) or I have to create one (with no idea 
> what magic mangler to call).
> 
> I'm asking this question here rather than on café as I feel that if 
> there is a solution, it's probably buried in the details of GHC.
> 
> Thanks for any suggestions,
> MarLinn
> 
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Can I get the internal name of a package at runtime?

[MarLinn]

Hi.

I'm experimenting with plug-ins right now. I did manage to dynamically 
load functions at runtime. The caveat: Something (cabal? ghc?) mangles 
the package names. For example, to load a function called "theFunction" 
from a module called "Callee" in a package "Plugin", I had to address it 
via the name 
"Pluginzm0zi0zi0zi0zm2QaFQQzzYhnKJSPRXA7VtPe_Callee_theFunction_closure". 
O…K. Most parts of that are clear, and thanks for making my package 
cooler by appending a "z", but who is this Ozi guy and why is he rapping 
about modems? Without knowing Ozi, the only way I found to get at this 
magic string is to manually look at the actual ELF-header of the 
compiled module. While that might be a robust way, it seems neither 
portable nor elegant.


The "plugins" library failed too, probably for the same reason. (Or it's 
under-documented. Probably both.) The "dynamic-loader" library does 
something via c, therefore no.


Which brings me to the question: Is there any way for a module to get at 
its own internal package name? Or even at the internal name of an 
external package? If not, can I somehow recreate the magic mangling at 
runtime? At first I thought the functions in the "Module", "Name" etc 
modules of GHC might help – but it seems I either need an existing Name 
(that I have no idea how to get) or I have to create one (with no idea 
what magic mangler to call).


I'm asking this question here rather than on café as I feel that if 
there is a solution, it's probably buried in the details of GHC.


Thanks for any suggestions,
MarLinn

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs