Cross Compiler

From Msim

Jump to: navigation, search

This page refers to issues involving the use of a cross compiler. M5sim.org has made a binary available here: Downloads

Contents

Compiler Options

    • Fortran options may be different (however, gfortran has worked and generated binaries).
  • "-g" used, but may not be needed
  • "-static" dynamic library linkage will not work in the simulated enviroment as the libraries are not available to the simulator
  • "-O4" (and other -O0, -O1, -O2, -O3, -O99). These are all valid but in some cases requires patching of the data segment
  • "-Wl,-S,-Tdata=0x140000000" at link time, remove all debug sections (this resolves the .data at address 0 issue) and set the data section to 0x140000000 (as per Alpha standard, the cross compiler may try to put the data section at 0x120000000). In some cases, the file will still indicate the original data section value incorrectly after objcopy.
  • "-mcpu=ev67" indicates the target architecture
  • "-DSPEC_CPU2000" (or variants such as -DSPEC_CPU2K6) this modifies the code for benchmarking purposes


Elf to Ecoff

objcopy -I elf64-alpha -O ecoff-littlealpha <source exe> <target exe>

Data Segment

In some cases, the benchmark may execute bogus opcodes or crash due to alignment faults. While there may be an underlying support issue involved, many of these problems have been resolved by patching the ECOFF header to indicate that the data segment starts at 0x140000000 (of course, this only works if it is reported incorrectly as 0x120000000). Currently, we have no idea why the header is fed the wrong information or if there are any unknown issues related to the data segment misplacement.

To modify, change the byte located at 0x4b from 0x20 to 0x40.
The following, somewhat excessive code, will perform the modifications through the command line (<exe> <alpha exe>)

#include<iostream>
#include<fstream>
#include<iomanip>

using namespace std;

int main(int argc, char ** argv)
{
 if(argc!=2)
 {
  cout << "Error in command line request. Proper format <exe> <file to patch>. Such as, \"ev6patch.exe gcc.ev6\"" << endl;
  return 1;
 }

 fstream file(argv[1], ios_base::in | ios_base::out | ios_base::binary);
 if(!file.is_open())
 {
  cout << "Can't open: " << argv[1] << endl;
  return 2;
 }

 char buffer[100];
 file.read(buffer,80);
 unsigned long long data(0);

 if(file.gcount()!=80)
 {
  cout << "Could not read enough data from " << argv[1] << endl;
  return 3;
 }

 int shiftleft(56);
 for(int i=0;i<8;i++)
 {
  data += ((unsigned long long)(buffer[0x4f-i]))<<shiftleft;
  shiftleft-=8;
 }

 cout << "Detected data section at: " << hex << data << endl;

 char towrite = 0x20, temp;

 if(data==0x120000000)
 {
  cout << "Data section may be misplaced in header, change to 0x140000000? (y/n): ";
  cin >> temp;
  if(temp=='y')
  {
   towrite = 0x40;
  }
 }
 else if(data==0x140000000)
 {
  cout << "Data section should be correct, however, change to 0x120000000? (y/n): ";
  cin >> temp;
 }
 else
 {
  cout << "Data section not found, change to 0x120000000? (y/n): ";
  cin >> temp;
 }

 if(temp=='y')
 {
  file.seekg(0x4b,ios_base::beg);
  file.write(&towrite,1);
 }

 file.close();
 return 0;
}

Input Issues

Apparently, scanf (at least scanf) is extraordinarily sensitive to the input. Consider the following input file:

15 10
20 30
40 50

In general, we could read it in as follows:

for(int i=0;i<3;i++)
{
  scanf("%d %d",&first, &second);
}

However, this appears to be a problem (internally, a comparsion is done against 0x0a (character by character) and then it never continues past the Line Feed).
The code needs to be explicit in terms of whitespace handling:

for(int i=0;i<3;i++)
{
  scanf("%d %d\n",&first, &second);
}


Additionally, this affects cin as well. Further examination shows that the locale "C" seems to have no idea about how to work correctly. For example:

for(int i=0;i<0x100;i++)
{
 if(isspace(i))
 {
  cout << "Ascii val " << i << " is whitspace." << endl;
 }
}

Shows that the values 9, 10, 11, 12, 13 and 32 are whitespace. However, during simulation, none of these values work. Adding locales from a debian installation allowed us to use "en_US.UTF-8" but without any difference - including throwing exceptions when trying to imbue cout/cin with the locale.
The use of "char" to eat the excess whitespace resolves the problem similarly as in the scanf case (unknown amounts of whitespace may still be an issue).

skipws

The skipws flag appears to be set and controllable during simulation. Changing the flag does not resolve the whitespace issues. All code needs to be modified to assume that "noskipws" is in effect.

Personal tools