Opened 3 years ago

Last modified 7 months ago

#9351 new feature request

add ability to version symbols .c for packages with C code

Reported by: slyfox Owned by:
Priority: normal Milestone:
Component: Compiler Version: 7.8.3
Keywords: backpack Cc: RyanGlScott
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

Let's consider an example:

We have a haskell package with some C code imported in haskell:

// a.h file
int get_something(void);

// a.c file
#include "a.h"
int get_something(void) { return 42; }

// M.hs file
module M where

foreign import ccall "a.h get_something" :: IO Int

The problem here is we can't mix that package with other packages having global 'get_something' symbol.

Sometimes it happens when a package copies part of implementation from another package with .c bits under different haskell namespace. Haskell parts would coexist freely, but not C symbols.

Would be great if ghc would export some unique package identifier in a way C code could attach it to all exported symbols making linking possible.

Something like that:

// a.h file
#include "HsFFI.h" /* #define FOR_HASKELL(__sym) package_id_##__sym */
int FOR_HASKELL(get_something)(void);

// a.c file
#include "a.h"
int FOR_HASKELL(get_something)(void) { return 42; }

// M.hs file
module M where

foreign import ccall-for-haskell "a.h get_something" :: IO Int

That way we explicitly mark symbol as inaccessible to external plain C code.

Change History (5)

comment:1 Changed 3 years ago by hvr

Fwiw, I'd rather have a macro for the .hs part as well than have yet another FFI calling convention. (it'd be useful in other cases as well, to have the ability to uniformly transform the ABI-level C symbol name; e.g. for GMP, all official function names are prefixed by __g prefix at the ABI level)

E.g. something like:

foreign import ccall C_PKG_NAME("a.h","get_something") :: IO Int

This will, however, require a better CPP than the current traditional CPP mode to work...

comment:2 Changed 3 years ago by slyfox

Yeah, it's just an idea of symbol mangling control.

Maybe macro introduction better be done on cabal's side?

comment:3 Changed 3 years ago by duncan

Or a more automagic approach might be to use binutils to rename or hide C symbols.

comment:4 Changed 2 years ago by ezyang

duncan: the problem with a more magic approach is that mangling the symbols could break uses of dlopen in the compiled objects, since you have no idea if a string is referring to a specific symbol.

comment:5 Changed 7 months ago by RyanGlScott

Cc: RyanGlScott added
Note: See TracTickets for help on using tickets.