[PATCH] D28898: [ELF] - Allow emulation to be different from input objects target.

[George Rimar via llvm-commits]

>> +// Create target. If emulation option specified then replace
>> +// target's default parameters with emulated target parameters.
>> +static TargetInfo *createEmulation() {
>> +  TargetInfo *Target = createTarget(Config->EKind, Config->EMachine);
>> +  if (Config->Emulation.empty())
>> +    return Target;
>> +
>> +  ELFKind EmuKind;
>> +  uint16_t EmuMachine;
>> +  uint8_t EmuOSABI;
>> +  std::tie(EmuKind, EmuMachine, EmuOSABI) = parseEmulation(Config->Emulation);
>> +
>> +  // OSABI is overriden when emulation is specified.
>> +  Config->OSABI = EmuOSABI;
>> +
>> +  TargetInfo *EmuTarget = createTarget(EmuKind, EmuMachine);
>> +  Target->PageSize = EmuTarget->PageSize;
>> +  Target->DefaultMaxPageSize = EmuTarget->DefaultMaxPageSize;
>> +  Target->DefaultImageBase = EmuTarget->DefaultImageBase;
>
>This is extremely suspicious. Can you end up with the AArch64 page on
>x86-64? Does bfd and gold accept all -m options or only cases like
>x86/x86-64?
>
>What test fails if you just ignore -m if there is a .o file?
>
>Cheers,
>Rafael

1) I took i386.o (32 bit) and performed next tests using bfd.gold
ld.gold -v
GNU gold (GNU Binutils 2.27) 1.12
(all outputs here and below were "Intel 80386" ELF32 binary for all cases).

Took output from next calls:
 a) ld.gold i386.o -o out
 b) ld.gold i386.o -o out -m elf_x86_64_nacl
 c) ld.gold i386.o -o out -m elf_x86_64
 tried powerpc and aarch64:
 d) ld.gold i386.o -o out -m elf64-powerpc
 e) ld.gold i386.o -o out -m aarch64_elf64_le_vec
 
For all cases output was the same:
[ 1] .text             PROGBITS        08048054 000054 000001 00  AX  0   0  4
Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000000 0x08048000 0x08048000 0x00055 0x00055 R E 0x1000

2) ld.bfd behaves differently, it reports a error if I give it some 'incompatible' emulation:
ld.bfd -m elf_x86_64 i386.o -o out
ld.bfd: i386 architecture of input file `i386.o' is incompatible with i386:x86-64 output

But if we have linkerscript with:
OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i386")
OUTPUT_ARCH(i386)

Then:
a) ld.bfd --script=realmode.lds -m elf_x86_64 i386.o -o out
[Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
 [ 1] .text             PROGBITS        00000000 200000 000001 00  AX  0   0  4
Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
 LOAD           0x200000 0x00000000 0x00000000 0x00001 0x00001 R E 0x200000
 
b) ld.bfd --script=realmode.lds -m elf_i386 i386.o -o out
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 1] .text             PROGBITS        00000000 001000 000001 00  AX  0   0  4
Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x001000 0x00000000 0x00000000 0x00001 0x00001 R E 0x1000

So here emulation option has some affect.

My bfds I have does not support aarch64/ppc emulations, I had not chance to check them.

Behavior of linkers is inconsistent. Honestly previously I tested it only with linkerscript (as it was my reproduce)
and did not know bfd failing without it. So I supposed it is correct to apply emulation options as it what bfd
do. 

But since main aim of patch is just to allow -m elf_x86_64 and i386 objects work together,
for simplicity I suggest to go with next behavior then:
1) Take machine output type from first object.
2) If that is not possible then take it from -m.
3) Do not change any target options if emulation is applied (like gold do).
4) Do not touch our OUTPUT_FORMAT/OUTPUT_ARCH impl for now either.

I'll do that change and update the patch.

George.