Added file compatibility check to ELFDynObjParser::parseFile function

[Steven6798]

Fixes the ELFDynObjParser::parseFile function. The function
was missing a check that throws an error when incompatible files
are detected.
Update WrongArchInput test to include dynamic linking.
Convert WrongArchInput test into a single common standalone test.
Update linker_faq doc to include information about linking
incompatible files.

Fixes #1097

[parth-07]

Do we need to check-in the shared libraries lib2.so in the codebase? Can we instead build the shared libraries as part of the test?

[Steven6798]

Do we need to check-in the shared libraries lib2.so in the codebase? Can we instead build the shared libraries as part of the test?

The shared library would have to be compiled for another target. I don't think it is a good idea to build them since the test would need that additional target to run. I could look into how does the yaml code works to build the lib2.so object file without having to include the binary or require the additional target. Let me know what approach you think is best.

[quic-areg]

I don't think any .so files need to be checked in with this patch. You should be able to produce an arch mismatch by using YAML and EM_NONE:

$ cat 1.yaml
--- !ELF
FileHeader:
  Class:           ELFCLASS32
  Data:            ELFDATA2LSB
  Type:            [[TYPE=ET_REL]]     
  Machine:         EM_NONE              
  ...

$ yaml2obj 1.yaml                  -o tmp.o   
$ yaml2obj 1.yaml -DTYPE=ET_DYN    -o tmp.so 
$ ld.eld -m elf_x86_64 -Bdynamic 1-x64.o ./tmp.so -o out
Fatal: cannot recognize the format of file `./tmp.so'. ...

Then, I think that this could be all one test under Common using %emulation and the target-specific ones (the new ones added in this PR and the existing ones under AArch64/ARM/Hexagon/{linux,standalone}/WrongArchObject) can be deleted.

[Steven6798]

I don't think any .so files need to be checked in with this patch. You should be able to produce an arch mismatch by using YAML and EM_NONE:

$ cat 1.yaml
--- !ELF
FileHeader:
  Class:           ELFCLASS32
  Data:            ELFDATA2LSB
  Type:            [[TYPE=ET_REL]]     
  Machine:         EM_NONE              
  ...

$ yaml2obj 1.yaml                  -o tmp.o   
$ yaml2obj 1.yaml -DTYPE=ET_DYN    -o tmp.so 
$ ld.eld -m elf_x86_64 -Bdynamic 1-x64.o ./tmp.so -o out
Fatal: cannot recognize the format of file `./tmp.so'. ...

Then, I think that this could be all one test under Common using %emulation and the target-specific ones (the new ones added in this PR and the existing ones under AArch64/ARM/Hexagon/{linux,standalone}/WrongArchObject) can be deleted.

That's a great idea! I'll add this change to the next commit I have planned for this PR.

[parth-07]

@Steven6798 @quic-areg Would it be better to simply have a very simple file with contents int foo() { return 1; } and then use it to build shared library instead of using yaml2obj? Is there any benefit of using yaml2obj here? My concern is that yaml2obj unnecessarily requires much more code than a basic C file.

[Steven6798]

@Steven6798 @quic-areg Would it be better to simply have a very simple file with contents int foo() { return 1; } and then use it to build shared library instead of using yaml2obj? Is there any benefit of using yaml2obj here? My concern is that yaml2obj unnecessarily requires much more code than a basic C file.

Using the simple C file requires another target to be built to create the shared library. I'm not sure if there are other tests that work that way, but I don't think this is a good idea to require multiple targets to be built to run a test unless it is absolutely necessary.

[parth-07]

Using the simple C file requires another target to be built to create the shared library. I'm not sure if there are other tests that work that way, but I don't think this is a good idea to require multiple targets to be built to run a test unless it is absolutely necessary.

Okay, I see. You are right. Let's proceed with yaml2obj.

[quic-seaswara]

@Steven6798 can you please squash the commits, and add a good commit message with a description of the change.

Also update the userguide if there is a way to document this behavior.