Re: [GHC] #1288: ghci 6.6 foreign import stdcall broken, panic, panic!!!!
#1288: ghci 6.6 foreign import stdcall broken, panic, panic -+-- Reporter: [EMAIL PROTECTED] | Owner: igloo Type: merge| Status: closed Priority: normal | Milestone: 6.8.3 Component: GHCi |Version: 6.6 Severity: critical | Resolution: fixed Keywords: ghci foreign ffi dll import stdcall | Difficulty: Moderate (1 day) Testcase: | Architecture: x86 Os: Windows | -+-- Changes (by igloo): * status: new = closed * resolution: = fixed Comment: Merged -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1288#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1288: ghci 6.6 foreign import stdcall broken, panic, panic!!!!
#1288: ghci 6.6 foreign import stdcall broken, panic, panic
-+--
Reporter: [EMAIL PROTECTED] | Owner: igloo
Type: merge| Status: new
Priority: normal | Milestone: 6.10 branch
Component: GHCi |Version: 6.6
Severity: critical | Resolution:
Keywords: ghci foreign ffi dll import stdcall | Difficulty: Moderate (1
day)
Testcase: | Architecture: x86
Os: Windows |
-+--
Changes (by simonmar):
* owner: simonmar = igloo
* type: bug = merge
Comment:
One bug fixed, remaining bug moved to #2283
To merge:
{{{
Wed May 14 02:27:42 PDT 2008 Simon Marlow [EMAIL PROTECTED]
* FIX #1288: GHCi wasn't adding the @n suffix to stdcalls on Windows
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1288#comment:10
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1288: ghci 6.6 foreign import stdcall broken, panic, panic!!!!
#1288: ghci 6.6 foreign import stdcall broken, panic, panic -+-- Reporter: [EMAIL PROTECTED] | Owner: igloo Type: merge| Status: new Priority: normal | Milestone: 6.8.3 Component: GHCi |Version: 6.6 Severity: critical | Resolution: Keywords: ghci foreign ffi dll import stdcall | Difficulty: Moderate (1 day) Testcase: | Architecture: x86 Os: Windows | -+-- Changes (by simonmar): * milestone: 6.10 branch = 6.8.3 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1288#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1288: ghci 6.6 foreign import stdcall broken, panic, panic!!!!
#1288: ghci 6.6 foreign import stdcall broken, panic, panic -+-- Reporter: [EMAIL PROTECTED] | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: GHCi |Version: 6.6 Severity: critical | Resolution: Keywords: ghci foreign ffi dll import stdcall | Difficulty: Moderate (1 day) Testcase: | Architecture: x86 Os: Windows | -+-- Changes (by simonmar): * milestone: 6.8 branch = 6.8.3 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1288#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1288: ghci 6.6 foreign import stdcall broken, panic, panic!!!!
#1288: ghci 6.6 foreign import stdcall broken, panic, panic +--- Reporter: [EMAIL PROTECTED] |Owner: simonmar Type: bug | Status: new Priority: normal |Milestone: 6.8 Component: GHCi | Version: 6.6 Severity: critical | Resolution: Keywords: ghci foreign ffi dll import stdcall | Difficulty: Moderate (1 day) Os: Windows | Testcase: Architecture: x86 | +--- Changes (by simonmar): * owner: = simonmar Comment: I'll look at this -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1288 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
ghci 6.6 foreign import stdcall broken, panic, panic!!!!
ghci 6.6 foreign import stdcall broken, panic, panic Hello I would like to report what I think is a problem with GHCI foreign function imports of c functions declared with stdcall calling convention (1) and also with loading objects containing dll imports (2). I will attempt to log this in ghc trac. What is the problem ? -- (1) Prelude :load htest3 [1 of 1] Compiling Main ( htest3.hs, interpreted ) During interactive linking, GHCi couldn't find the following symbol: test This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs@haskell.org (2) ghci -fglasgow-exts test_proxy5a.o -ltest3b test_proxy5a.o: unknown symbol `__imp__test' final link ... : linking extra libraries/objects failed detail follows ... CONCLUSSION REACHED (1) ghci handling of mangling of stdcall function names broken. (2) ghci loading of c object files dll imports name resolution broken. (1) ghci dose not correctly look for symbols decorated in the stdcall manner in the object files ie. it looks for _test when it should (according to stdcall convention) look for [EMAIL PROTECTED] stdcall symbols in object files are decorated with the number of bytes that should be popped from the stack before the function returns. (2) ghci cannot properly resolve dllimports in c object files i.e. if an object loaded by ghci (eg test_proxy, with c function test_proxy) calls functions from a dll (eg test) then that function in the object file will be decorated as this in normal course linked agains a .lib or a .a file will be resolved to _test function in the dll but ghci does not do this. ofcourse these problems go away when using ghc ... but well what's the point of ghci then? SUMMARY OF TESTS and METHODOLOGY 1) REFERENCE CASE verify that ccall works .. Create c file test1a.c and function test(int) in the file create haskell file htest1.hs with function ctest calling test check this works ok with (a) c object loaded (test1a.c, htest1.hs )-- OK, RIGHT! (b) windows dll, c is function dll export (test1b.c, htest1.hs ) -- OK, RIGHT! 3) change calling convention to stdcall (a) check loading of function from object (test3a.c, htest3.hs) -- FAIL, WRONG (b) check loading of stdcall function from dll -- FAIL, WRONG 4) try what shouldn't work (a) htest3 against object test1a, i.e. what hapens when you try loading a haskell module with foreign import stdcall against c function declared with ccall convention ghci loaded -- OK!!, WRONG, it should not have resolved the symbol and not loaded ghc called function and crashed -- given that it resolved the symbol and called the function this is expected (b) htest3 against dll htest1b.dll same result as 4a -- expected, behaviour consistent in both cases with resolving stdcall callouts (symbols test) in a manner consistent with ccalls i.e. resolving the call to c function test as a call to symbol _test rather than [EMAIL PROTECTED] as it should be according to stdcall convention yet the function is called as stdcall c function consequently ghci crashes when the ccall function returns and the stack has not been cleared of the function arguments as is required by the stdcall convention 5) Hmm, lets see what happens when we have a ccall c proxy function calling stdcall c function in dll etc? (a) test_proxy5a.o with test3b.dll ccall function calling stdcall function in dll unknown symbol __imp__test -- FAILED, WRONG dllimports are decorated with __imp__ so a stdcall dllimport to a c function test will appear as [EMAIL PROTECTED] the dll will export symbol [EMAIL PROTECTED], usually it is the function of the import library .a or .lib depending upon which linker mingw or msvc to resolve [EMAIL PROTECTED] to reference [EMAIL PROTECTED] in dll (b) test_proxy5b.o with test3b.dll, htest5.hs ccall function calling stdcall function (not declared as dllimport) LOADS OK, RUNS OK test_proxy5b imports symbol [EMAIL PROTECTED] the test3b.dll exports symbol [EMAIL PROTECTED] arguably this is correct behaviour as __imp__ decoration is an MS innovation and case (a) should be handled together with case (b). (c) whell what about test_proxy5b.o with test1b.dll i.e. c stdcall to a c function declared with ccall convention from .o object loaded by ghci should fail to resolve symbols, should crash program does niether hey this has me stumped
Re: [GHC] #1288: ghci 6.6 foreign import stdcall broken, panic, panic!!!!
#1288: ghci 6.6 foreign import stdcall broken, panic, panic +--- Reporter: [EMAIL PROTECTED] |Owner: Type: bug | Status: new Priority: normal |Milestone: Component: GHCi | Version: 6.6 Severity: critical | Resolution: Keywords: ghci foreign ffi dll import stdcall | Difficulty: Moderate (1 day) Os: Windows | Testcase: Architecture: x86 | +--- Changes (by simonmar): * priority: high = normal Comment: Thanks for the detailed report, we'll assign priority in due course. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1288 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #1288: ghci 6.6 foreign import stdcall broken, panic, panic!!!!
#1288: ghci 6.6 foreign import stdcall broken, panic, panic
---+
Reporter: [EMAIL PROTECTED] | Owner:
Type: bug | Status: new
Priority: high| Milestone:
Component: GHCi| Version: 6.6
Severity: critical|Keywords: ghci foreign ffi dll import
stdcall
Difficulty: Moderate (1 day)|Testcase:
Architecture: x86 | Os: Windows
---+
'''ghci 6.6 foreign import stdcall broken, panic, panic'''
I would like to report what I think is a problem with GHCI foreign
function imports
of c functions declared with stdcall calling convention (1) and also with
loading objects containing dll imports (2).
= WHAT IS THE PROBLEM ? =
== 1. ghci handling of mangling of stdcall function names broken ==
{{{
Prelude :load htest3
[1 of 1] Compiling Main ( htest3.hs, interpreted )
During interactive linking, GHCi couldn't find the following symbol:
test
This may be due to you not asking GHCi to load extra object files,
archives or DLLs needed by your current session. Restart GHCi, specifying
the missing library using the -L/path/to/object/dir and -lmissinglibname
flags, or simply by naming the relevant files on the GHCi command line.
Alternatively, this link failure might indicate a bug in GHCi.
If you suspect the latter, please send a bug report to:
glasgow-haskell-bugs@haskell.org
}}}
== 2. ghci loading of c object files dll imports name resolution broken ==
{{{
ghci -fglasgow-exts test_proxy5a.o -ltest3b
test_proxy5a.o: unknown symbol `__imp__test'
final link ... : linking extra libraries/objects failed
}}}
detail follows ...
= CONCLUSSION REACHED =
== 1. Importing Stdcall Symbols ==
ghci dose not correctly look for symbols decorated in the stdcall manner
in the
object files ie. it looks for '''_test''' when it should (according to
stdcall convention) look for '''[EMAIL PROTECTED]'''.
stdcall symbols in object files are decorated with the number of bytes
that should
be popped from the stack before the function returns.
== 2. linking objects with dllimports ==
ghci cannot properly resolve dllimports in c object files i.e. if an
object loaded by ghci
(eg test_proxy, with c function test_proxy) calls functions from a dll (eg
'''test''') then
that function in the object file will be decorated as '''`__imp__test`'''
this in normal course linked agains a .lib or a .a file will be resolved
to '''_test'''
function in the dll but ghci does not do this.
Offcourse these problems go away when using ghc ... but well what's the
point of ghci then?
= SUMMARY OF TESTS and METHODOLOGY =
== 1. Reference Case ==
verify that ccall works ..
[[BR]]Create c file test1a.c and function test(int) in the file
[[BR]]create haskell file htest1.hs with function ctest calling test
[[BR]]check this works ok with
a. c object loaded (test1a.c, htest1.hs )-- OK, RIGHT [[BR]]
b. windows dll, c is function a dll export (test1b.c, htest1.hs ) --
OK, RIGHT
== 3. change calling convention to stdcall ==
a. check loading of function from object (test3a.c, htest3.hs) -- FAIL,
WRONG[[BR]]
b. check loading of stdcall function from dll -- FAIL, WRONG
== 4. try what shouldn't work ==
a. htest3 against object test1a
i.e. what hapens when you try loading a haskell module with foreign
import stdcall against c function declared with ccall convention.
ghci loaded -- OK!!, WRONG,
it should not have resolved the symbol and not loaded.[[BR]]
ghci called the function and crashed -- given that it resolved the
symbol and called the function, this is expected.
b. htest3 against dll htest1b.dll
same result as 4a -- expected,
behaviour consistent in both cases with resolving stdcall callouts
(symbol '''test''') in a manner consistent with ccalls.
i.e. resolving the call to c function '''test''' as a call to symbol
'''_test'''
rather than '''[EMAIL PROTECTED]''' as it should be according to the stdcall
convention.
yet the function is called as a stdcall c function, consequently ghci
crashes when
the ccall function returns and the stack has not been cleared of the
function arguments, as is required by the stdcall convention.
== 5. Lets try a proxy function/object ==
Hmm, lets see what happens when we have a ccall c proxy function calling
stdcall c
function in dll etc?
a. test_proxy5a.o with test3b.dll
ccall function calling stdcall function in dll
{{{
unknown symbol __imp__test
}}}
FAILED
Re: [GHC] #1288: ghci 6.6 foreign import stdcall broken, panic, panic!!!!
#1288: ghci 6.6 foreign import stdcall broken, panic, panic
-+--
Reporter: [EMAIL PROTECTED] | Owner:
Type: bug | Status: new
Priority: high | Milestone:
Component: GHCi |Version: 6.6
Severity: critical | Resolution:
Keywords: ghci foreign ffi dll import stdcall | Difficulty: Moderate (1
day)
Testcase: | Architecture: x86
Os: Windows |
-+--
Comment (by [EMAIL PROTECTED]):
error in transcription, the above should read...
=== test_proxy5b.c ===
{{{
#include stdio.h
extern void _stdcall test(int arg);
void test_proxy(int arg)
{
test(arg);
}
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1288
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1288: ghci 6.6 foreign import stdcall broken, panic, panic!!!!
#1288: ghci 6.6 foreign import stdcall broken, panic, panic -+-- Reporter: [EMAIL PROTECTED] | Owner: Type: bug | Status: new Priority: high | Milestone: Component: GHCi |Version: 6.6 Severity: critical | Resolution: Keywords: ghci foreign ffi dll import stdcall | Difficulty: Moderate (1 day) Testcase: | Architecture: x86 Os: Windows | -+-- Comment (by guest): appon reflection 5c of above ... hey this has me stumped test_proxy5b.o imports symbol [EMAIL PROTECTED] test1b.dll exports symbol _test hmmm how is the symbol [EMAIL PROTECTED] resolved ??? why isn't the stack corrupted when test is called ??? MYSTERY ??? if ghci is doing the linking and uses the same name resolution to resolve these names i.e. '''[EMAIL PROTECTED]''' is dropping the '''@4''' to get '''_test''' then it would make sense that linking is successful. But why dosn't it crash when called? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1288 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1288: ghci 6.6 foreign import stdcall broken, panic, panic!!!!
#1288: ghci 6.6 foreign import stdcall broken, panic, panic -+-- Reporter: [EMAIL PROTECTED] | Owner: Type: bug | Status: new Priority: high | Milestone: Component: GHCi |Version: 6.6 Severity: critical | Resolution: Keywords: ghci foreign ffi dll import stdcall | Difficulty: Moderate (1 day) Testcase: | Architecture: x86 Os: Windows | -+-- Comment (by [EMAIL PROTECTED]): in preceeding comment ... but if this is the case '''[EMAIL PROTECTED]''' should not successfully link against '''[EMAIL PROTECTED]''' in test5b. Hmmm, Mystery ??? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1288 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
