将值按结构传递给Linux 64位上的P / Invoked库?

时间:2013-06-26 22:15:11

标签: c# linux mono g++ pinvoke

我正在尝试获取我用于在Linux x86_64上编译的C#库的本机依赖项。代码本身与平台无关,可以轻松编译。

但是,在首次尝试在Linux上运行带有编译依赖项的项目之后,我开始从库中获得奇怪的结果,稍后又会出现段错误。经过一些调查后,似乎P / Invoke函数上的参数没有按正确的顺序传递。似乎他们被倒退了。

我尝试用几种不同的方式编译本机依赖项,​​并明确定义不同的调用约定。似乎没什么用。

C#extern方法定义

[DllImport(InteropUtil.PLATFORM_DLL)]
public static extern NavStatus dtqFindPath(IntPtr query
    , NavmeshPoint startPosition
    , NavmeshPoint endPosition
    , IntPtr filter
    , [In, Out] uint[] resultPath
    , ref int pathCount
    , int maxPath);

相关C ++定义

#if _MSC_VER    // TRUE for Microsoft compiler.
#define EXPORT_API __declspec(dllexport) // Required for VC++
#else
#define EXPORT_API // Otherwise don't define.
#endif

extern "C"
{

    EXPORT_API dtStatus dtqFindPath(dtNavMeshQuery* query 
        , rcnNavmeshPoint startPos
        , rcnNavmeshPoint endPos
        , const dtQueryFilter* filter
        , dtPolyRef* path
        , int* pathCount
        , const int maxPath)
    {
        return query->findPath(startPos.polyRef
            , endPos.polyRef
            , &startPos.point[0]
            , &endPos.point[0]
            , filter
            , path
            , pathCount
            , maxPath);
    }
}

g ++编译器设置

g++ -shared -o cai-nav-rcn.so.1 -g -fPIC -I Detour/Include -I DetourCrowd/Include -I Nav/Include Detour/Source/*.cpp DetourCrowd/Source/*.cpp Nav/Source/*.cpp

在下面的输出中,dtqFindPath行清楚地显示了无序参数。 maxPath应该是100(0x64),而不是1298。 1298是int结构中的第一个startPos。 100是path的值。

部分GDB输出

Thread 1 (Thread 0x7fef64330740 (LWP 3923)):
#0  0x00007fef63823ce9 in waitpid () from /usr/lib/libpthread.so.0
#1  0x00000000004ae448 in ?? ()
#2  0x0000000000503b8b in ?? ()
#3  0x00000000004226b2 in ?? ()
#4  <signal handler called>
#5  0x00007feef052339c in dtNavMeshQuery::findPath (this=0x5405610, startRef=88101520, endRef=4203419680, startPos=0x7fff5fd3975c, endPos=0x7fff5fd3974c, filter=0x7fef64176ec0, path=0x64, pathCount=0x44d6595341be38e0, maxPath=1298) at Detour/Source/DetourNavMeshQuery.cpp:958
#6  0x00007feef0534d19 in dtqFindPath (query=0x5405610, startPos=..., endPos=..., filter=0x7fef64176ec0, path=0x64, pathCount=0x44d6595341be38e0, maxPath=1298) at Nav/Source/DetourNavMeshQueryEx.cpp:234
#7  0x0000000041ec2140 in ?? ()
...
#17 0x0000000005405610 in ?? ()
#18 0x0000000000000000 in ?? ()

我已经比较了两端rcnNavmeshPointNavmeshPoint结构的大小,它们是相同的。进入P / Invoke调用的参数顺序正确,用调试器检查。

可能还包括我正在尝试使用的库是CritterAI

所以我的问题是:我应该改变什么来获得这两段代码之间的调用约定?


更新

我解决了这个问题。这是没有正确传递的结构。我已经创建了一个SSCCE来证明这一点:

interop.cpp

#include <cstdio>

#if _MSC_VER
#define EXPORT_API __declspec(dllexport)
#else
#define EXPORT_API 
#endif

struct s
{
    unsigned int a;
    float b[3];
};

extern "C"
{
    EXPORT_API void testStruct(s str)
    {
        printf("STRUCT NATIVE\n");
        printf("SIZE: %u\n", sizeof(s));
        printf("%u, (%f, %f, %f)\n", str.a, str.b[0], str.b[1], str.b[2]);
    }
}

cs.cs

using System;
using System.Runtime.InteropServices;

namespace InteropTest
{
    [StructLayout(LayoutKind.Sequential)]
    public struct v
    {
        public float X;
        public float Y;
        public float Z;
    }

    [StructLayout(LayoutKind.Sequential)]
    public struct s
    {
        public uint A;
        public v B;
    }

    public class Test
    {
        [DllImport("./test.so")]
        public static extern void testStruct(s str);

        unsafe static void Main(string[] args)
        {
            s mStr;
            mStr.A = 22;
            mStr.B.X = 33f;
            mStr.B.Y = 44f;
            mStr.B.Z = 55f;
            Console.WriteLine("STRUCT MANAGED");
            Console.WriteLine("SIZE: " + sizeof(s));
            Console.WriteLine(mStr.A + ", (" + mStr.B.X + ", " + mStr.B.Y + ", " + mStr.B.Z + ")");
            testStruct(mStr);
        }
    }
}

已编译

g++ -shared -o test.so -g -fPIC interop.cpp && mcs /unsafe cs.cs && ./cs.exe

我系统上的输出

STRUCT MANAGED
SIZE: 16
22, (33, 44, 55)
STRUCT NATIVE
SIZE: 16
22, (33.000000, 0.000000, 3.179688)

其他一些测试显示结构被“跳过”,其中打印str.a将打印出下一个非结构参数的值。结构的其余部分似乎是垃圾。

1 个答案:

答案 0 :(得分:2)

注意:以下答案解决了问题的原始版本。

在Linux x86_64上只有一个调用约定。它被称为System V AMD64 ABI。无论不匹配是什么,它肯定不在调用约定中。也许结构声明不匹配,或者我们看不到其他错误。

接下来我要做的就是编写一些简单的测试代码。我写了一个C ++函数,它接收了一对int个参数。检查它们是否以正确的顺序通过。说服自己调用约定不是问题,然后深入挖掘以找出问题的真正原因。