Không thể liên kết OpenCL trên Windows với GHC

Question

Tôi đang cố gắng để có được các ràng buộc OpenCLRaw đến một điểm mà tôi có thể sử dụng chúng trên các cửa sổ. Tôi đã chia rẽ repo OpenCLRaw trên github để tôi có thể sửa đổi nếu cần. Chi nhánh của tôi ở đây: https://github.com/dagit/OpenCLRaw

Tôi chủ yếu làm việc từ chi nhánh "FunPtr" của mình. Vấn đề tôi gặp phải là: Tôi đã cài đặt SDK OpenCL của AMD, chuyển đổi tệp .lib cụ thể của Visual Studio thành tệp mà gcc có thể xử lý (tệp .a), nhưng ghc dường như không liên kết với nó . Tôi nhận được các ký hiệu không xác định cho mọi thứ tôi sử dụng trong API OpenCL.

Tôi có thể tạo chương trình C "nhỏ" và liên kết nó bằng tệp .a mà tôi đã tạo và gcc từ mingw (không phải từ cài đặt Haskell). Tôi đang sử dụng phiên bản Windows mới nhất của nền tảng Haskell.

Đây là những bước tôi đã sử dụng để tạo ra các tập tin .a: http://forums.amd.com/forum/messageview.cfm?catid=390&threadid=138890

tôi đã sử dụng các lệnh trong ví dụ kịch bản (ví dụ, gendef và dlltool). Tôi đã cố gắng sử dụng 32 bit mọi thứ càng nhiều càng tốt, như tôi biết rằng GHC sẽ muốn tất cả mọi thứ là 32bit, vì vậy tôi không nghĩ rằng đó là một vấn đề 32bit so với 64bit.

Có ai biết nếu có điều gì đó khác biệt về cách gọi gcc dưới ghc thay vì gcc mà tôi nhận được từ mingw không?

Tôi cũng đã chơi với dòng lệnh ghc (Tôi đã sử dụng cabal-dev --verbose = 3 để kiểm tra dòng lệnh) và tôi vẫn không thể làm mát nó thành trạng thái hoạt động.

Mọi trợ giúp sẽ được đánh giá cao!

Answer 1

OpenCL sử dụng quy ước stdcall, nhưng OpenCLRaw đang sử dụng ccall. Điều này tạo ra một số vấn đề. Điều chính là người liên kết muốn các ký hiệu tên hàm kết thúc bằng @NN, nơi NN phụ thuộc vào hàm.

Khi nó quay ra, cách chính xác để tạo ra libOpenCL.a là như sau (từ một vỏ mingw):

cp /c/Windows/System32/OpenCL.dll . 
gendef OpenCL.dll 
dlltool -l libOpenCL.a -d OpenCL.def -k -A 

này sẽ tạo ra libOpenCL.a rằng GHC có thể sử dụng một cách chính xác để liên kết, nhưng chỉ nếu OpenCLRaw được sửa đổi để sử dụng lệnh stdcall thay vì ccall.

Bây giờ tôi đã hiểu được sự cố tôi có thể sửa các liên kết OpenCLRaw để thực hiện điều đúng trên Windows.

Khi tôi sử dụng pexports thay vì gendef, tôi có thể xóa @NN khỏi tên biểu tượng, nhưng sau đó chương trình kết quả bắt đầu bị phân đoạn. Điều này là do biểu tượng đã được tìm thấy nhưng quy ước gọi là không chính xác, có thể dẫn đến các ngăn xếp bị hỏng.

Bài học chính cho tôi là ràng buộc FFI của bạn phải phù hợp với quy ước gọi điện của thư viện C của bạn.