Harendra Kumar <[email protected]> writes: > On 12 November 2017 at 23:18, Ben Gamari <[email protected]> wrote: > >> In general it's not easy to get a reference to a an arbitrary function >> in an object file by it's source name. Unless the symbol is exported the >> compiler is free to optimize the function or even drop it altogether. >> > > I understand that. I was also wondering if there is way (some sort of > annotation, pragma or any other workaround) to keep the symbols around > without actually exporting them. Exporting either clobbers the module > interface from user point of view or the modules need a wrapper to avoid > exporting such symbols in user exposed modules. I would also expect an > option to remove the effect of any such annotation so that the production > build is not under optimized because of this. This is in fact one of the > problems that I have been facing in general. I do not know of a good way to > hide symbols from users but use them in tests and benchmarks during dev. > What is the GHC recommended way to achieve this? > The usual way of dealing with this is to expose the symbols from a `.Internal` module.
>> If you can guarantee that the functions you are about are exported then >> in principle you could probably do what you ask from a library. Just >> `dlopen` the executable (which would need to be compiled as a position >> independent exectuable), and dlsym the appropriately mangled name. >> > > Yeah that is a good option for dynamically linked executables. In fact I > have been using dlopen to implement Haskell plugins but did not think of > using it for this use case. Thanks for reminding me. In a static > executable, does it make sense to make the RTS choose an exported symbol as > entry point using an RTS option? > I don't see much precedent for this in other compilers. Moreover, I am generally not convinced that it should be the compiler's job to provide such a feature when the same end could be reached with far less magic by the user. Cheers, - Ben
signature.asc
Description: PGP signature
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
