MIPS 和 Intel C 编译器之间的宏定义兼容吗?

发布于 2024-09-03 05:36:57 字数 606 浏览 9 评论 0原文

我在 C 程序中定义的宏似乎有问题。

我用MIPS编译器编译了这个软件并成功运行了它。

它构建正常,但在使用 icc 时在运行时抛出错误“分段错误”。

我在 64 位架构上编译了这两个版本(SGI 上的 MIPS,带有 -64 标志和 intel 平台上的 icc)。

我需要使用一些神奇的开关才能使其在两个系统上正常工作吗?我打开了英特尔编译器的警告,程序中调用宏的每一处都会引发警告。通常是宏参数类型不匹配(int 到 char *)或类似的事情。

这是有问题的宏,

 #define DEBUG_ENTER(name) {tdepth++; 
 if(tnames[tdepth] == NULL) tnames[tdepth] = memalign(8, sizeof(char)*MAXLEN);
 strcopy(tnames[tdepth],name);
 FU_DEBUG("Entering \n");}

它基本上用于调试 - 根据函数调用的数量打印到带有一组选项卡的日志文件。 (t深度 = 选项卡深度)

我在手册页中做了一些检查。似乎 memalign 仅在 IRIX 上受支持。这可能是我的问题。我要去追踪它。

I seem to be having a problem with a macro that I have defined in a C program.

I compile this software and run it sucessfully with the MIPS compiler.

It builds OK but throws the error "Segmentation fault" at runtime when using icc.

I compiled both of these on 64 bit architectures (MIPS on SGI, with -64 flag and icc on an intel platform).

Is there some magic switch I need to use to make this work correctly on both system? I turned on warnings for the intel compiler, and EVERY one of the places in my program where a macro is invoked throws a warning. Usually something along the lines of mismatched types on the macro's parameters (int to char *) or some such thing.

Here is the offending macro

 #define DEBUG_ENTER(name) {tdepth++; 
 if(tnames[tdepth] == NULL) tnames[tdepth] = memalign(8, sizeof(char)*MAXLEN);
 strcopy(tnames[tdepth],name);
 FU_DEBUG("Entering \n");}

This basically is used for debugging - printing to a log file with a set number of tabs in based on how many function calls there are. (tdepth = tab depth)

I did some checking around in man pages. it seems like memalign is only supported on IRIX. This may be my problem. I am going to track it down.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

成熟的代价 2024-09-10 05:36:57

这可能与系统的“字节顺序”有关。看看这里,MIPS 似乎具有可切换的字节序。我不确定您是否已经使用了正确的字节顺序,但如果没有,您肯定会遇到问题。

This might have to do with the system's "endianness." Looking here it seems that MIPS has switchable endianness. I'm not sure if you are using the correct endianness already, but if you aren't, you will DEFINATELY have problems.

孤者何惧 2024-09-10 05:36:57

这可能是字节顺序问题。 MIPS 可以是大尾数,但英特尔是小尾数。

This might be a byte order issue. MIPS can be big endian but intel is little endian.

高跟鞋的旋律 2024-09-10 05:36:57

听起来数组 tnames 是一个 int 数组。如果您要为其分配指针,它应该是指针类型的数组 - 在这种情况下, char * 可能是合适的。

(此外,strcopy() 不是标准函数 - 您确定不是指 strcpy() 吗?)

It sounds like the array tnames is an array of int. If you're assigning pointers to it, it should be an array of a pointer type - in this case probably char * is appropriate.

(Also, strcopy() isn't a standard function - are you sure you don't mean strcpy()?)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文