MIPS memcpy 问题(我认为)
我有一些在 Redhat 系统上使用 icc 运行的软件,并且运行良好。当我将代码移植到运行 MIPS 的 IRIX 系统时,我得到一些计算结果,结果显示为“nan”,而那里肯定应该有值。
我在非 Redhat 系统上没有任何好的调试器,但我发现我的一些数组偶尔会出现“nan”,这导致我的点积计算返回为“nan”。
鉴于我无法使用调试器追踪它,我认为问题可能出在 memcpy 上。使用动态分配数组的 MIPS 编译器 memcpy() 函数是否存在任何问题?我基本上正在使用
memcpy(to, from, n*sizeof(double));
而且我无法真正证明这一点,但我认为这可能是问题所在。有一些解决方法吗?也许中小企业数据不一致?我该如何解决这个问题?
I have some software that I have working on a redhat system with icc and it is working fine. When I ported the code to an IRIX system running with MIPS then I get some calculations that come out as "nan" when there should definitely be values there.
I don't have any good debuggers on the non-redhat system, but I have tracked down that some of my arrays are getting "nan" sporadically in them and that is causing my dot product calculation to come back as "nan."
Seeing as how I can't track it down with a debugger, I am thinking that the problem may be with a memcpy. Are there any issues with the MIPS compiler memcpy() function with dynamically allocated arrays? I am basically using
memcpy(to, from, n*sizeof(double));
And I can't really prove it, but I think this may be the issue. Is there some workaround? Perhaps sme data is misaligned? How do I fix that?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
如果您的问题来自于
memcpy
中的错误,我会感到惊讶。这可能是对齐问题:您的 double 是否足够对齐? (如果您仅将它们存储在double
或double[]
对象中或通过double*
指针,它们就会是,但如果您移动它们,则可能不会通过void*
指针)。 X86 平台比大多数平台更能容忍错位。您是否尝试使用 gcc 在高警告级别编译代码? (除了微控制器或大型机之外,Gcc 几乎可以在任何地方使用。它可能会生成较慢的代码,但比“本机”编译器具有更好的诊断能力。)
当然,它始终可能是缓冲区溢出或某些不相关部分中的其他内存管理问题。刚刚发生的代码不会在您的原始平台上造成任何可见的错误。
如果您无法访问良好的调试器,请至少尝试在关键位置打印内容。
I'd be surprised if your problem came from a bug in
memcpy
. It may be an alignment issue: are yourdouble
s sufficiently aligned? (They will be if you only store them indouble
ordouble[]
objects or throughdouble*
pointers but might not be if you move them around viavoid*
pointers). X86 platforms are more tolerant to misalignment than most.Did you try compiling your code with gcc at a high warning level? (Gcc is available just about everywhere that's not a microcontroller or mainframe. It may produce slower code but better diagnostics than the “native” compiler.)
Of course, it could always be a buffer overflow or other memory management problem in some unrelated part of the code that just happened not to cause any visible bug on your original platform.
If you can't get a access to a good debugger, try at least printf'ing stuff in key places.
内存区域
to
和from
是否可以重叠?不需要memcpy
来处理重叠的内存区域。如果这是您的问题,那么解决方案就像使用 memmove 一样简单。Is it possible for the memory regions
to
andfrom
to overlap?memcpy
isn't required to handle overlapping memory regions. If this is your problem then the solution is as simple as using memmove instead.sizeof()
绝对支持吗?Is
sizeof()
definitely supported?