I chopped down my make file so I can compile a C++ program with very few, but some flags set to see if I can determine if they are working. The following is my make file section on C++ flags:

# Common compiler flags
CFLAGS = -mips1 -Wa,-non_shared \
         -mno-abicalls \
         -I. -I$(SESCSOURCEDIR)/src/libapp \
         -I$(SESCSOURCEDIR)/src/libacc \
         -I$(XTOOLSPREFIX)/mipseb-linux/include
# C++ flags
CXXFLAGS = $(CFLAGS) \
        -I$(XTOOLSPREFIX)/mipseb-linux/include/c++/3.2 \
        -I$(XTOOLSPREFIX)/mipseb-linux/include/c++/3.2/mips-linux-gnu \
        -I$(MINTTOOLSPREFIX)/libapp/

When I compile a program using this makefile I then run readelf on the elf file. This is the file's header:

ELF Header:
  Magic:   7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF32
  Data:                              2's complement, big endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           MIPS R3000
  Version:                           0x1
  Entry point address:               0x10000030
  Start of program headers:          52 (bytes into file)
  Start of section headers:          3611896 (bytes into file)
  Flags:                             0x10001001, noreorder, o32, mips2
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         4
  Size of section headers:           40 (bytes)
  Number of section headers:         31
  Section header string table index: 28

Note that the flags do not match. Why is this? Is there some sort of default configuration that I must override for the correct flags to take affect? Note that the output of make says that the correct flags have been applied although the ELF file doesn't represent this.

Make output:

/home/seas/grad/dasnyder/cmplrs/bin/mipseb-linux-g++ -mips1 -Wa,-non_shared -mno-abicalls -I. -I/src/libapp -I/src/libacc -I/home/seas/grad/dasnyder/cmplrs/mipseb-linux/include -I/home/seas/grad/dasnyder/cmplrs/mipseb-linux/include/c++/3.2 -I/home/seas/grad/dasnyder/cmplrs/mipseb-linux/include/c++/3.2/mips-linux-gnu -I/home/seas/grad/dasnyder/sesc//libapp/ -c test.cpp -o test.o
/home/seas/grad/dasnyder/cmplrs/bin/mipseb-linux-gcc test.o -Wl,--script=/home/seas/grad/dasnyder/dan/mint.x -L/home/seas/grad/dasnyder/cmplrs/src/mipseb-linux/lib -lstdc++ -lm -L/obj/mipseb_obj -L/home/seas/grad/dasnyder/cmplrs/mipseb-linux/lib -L/home/seas/grad/dasnyder/cmplrs/mipseb-linux/lib -lstdc++ -lm -o test

Recommended Answers

All 3 Replies

For MIPS, each ELF object module keeps track of its own OMF flags. The linker copies the appropriate flags from the original object module; if two different files have different sets of flags, unless they are conflicting flags, the more restrictive one is applied and a dignostic is generated: "xxx.o uses different e_flags (0xyyy) than previous modules (0xzzz)"


The extra flag present is EF_MIPS_NOREORDER. This flag was set because somewhere in the code for an object file, a .noreorder directive was given. The assembler is free to reorder instructions to avoid pipeline delays; .noreorder disables this. There would not be any problems related to this flag differing between your original object modules and the final module.

The flag that is differing is E_MIPS_ARCH_2 (mips2). The executable was linked with at least one module compiled for the mips2 architecture. Because of this, you need to run the program on an ARCH2 or ARCH3 processor, and it would run fine.

The -mno-abicalls (do not generate PIC) and -non_shared (link against static libraries) only affects how the code is generated and what object modules are linked in; they would not appear in the elf header.

When you say to run the program on an ARCH2 or 3 processor what exactly do you mean? I very specifically need to run on the MIPSI ISA and more importantly I need some sort of control over what ISA I'm compiling in. Do you mean set the march flag to the MIPSI processors like R2k or R3k?

> When you say to run the program on an ARCH2 or 3 processor what exactly do you mean?

Run on any 32-bit MIPS processor other than the original R2000 and R3000 processors.


> I very specifically need to run on the MIPSI ISA and more importantly
> I need some sort of control over what ISA I'm compiling in.
> Do you mean set the march flag to the MIPSI processors like R2k or R3k?

You have already set the march flag to MIPSI ISA for the files that you are compiling by specifying -mips1. The elf flag is MIPS ARCH2 because some of the libraries that you are linking with have been compiled for MIPS ARCH2 ISA.

Since you are not linking to shared libraries (by specifying -non_shared), fixing this is easy. In a separate directory, stage builds of the libraries that you are using (just libc and libstdc++ as far as I can make out) with the -mips1 flag. And then link to these staged libraries statically. The elf e_flag for the executable will then be mips1 and you can run the program on any 32-bit mips processor.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.