tags:

views:

75

answers:

3

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.

A: 

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

Amardeep
What kind of operations are affected by this? I am not doign any explicit byte shifting or anything. Wont the normal system calls (malloc,, memset, etc, be ok?)
Derek
There are so many things that can be affected it is hard to summarize. System calls should be okay but their parameters may not. If you can post the macro I'm sure someone will point out the problem quite rapidly.
Amardeep
It is posted...
Derek
Okay, the first thing that jumps out is memalign() returns void * and is being assigned to what I assume would be a char *. That would explain the warning from icc. The second thing is you are not testing the return value to see if the call succeeded. Check for NULL again before the strcpy(). Also memalign() is considered obsolete. Try using posix_memalign() instead.
Amardeep
+1  A: 

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.

samoz
A: 

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()?)

caf