maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lld/test/ELF/no-obj.s

11 lines
295 B
ArmAsm
Raw Normal View History

[LLD] Mark a number of x86 only tests to require x86 Noticed while testing for an out of tree target. There are probably more tests that should be so marked. I'm not sure who owns these tests so I've added a few names I recognise from the recent history. With advice from probinson, ruiu, rafael and dramatically improved by davidb. Thank you all! Differential Revision: https://reviews.llvm.org/D34685 llvm-svn: 308335
2017-07-19 02:40:50 +08:00
// REQUIRES: x86
ELF2: Make SymbolTable a template class. SymbolTable was not a template class. Instead we had switch-case-based type dispatch to call desired functions. We had to do that because SymbolTable was created before we know what ELF type objects had been passed. Every time I tried to add a new function to the symbol table, I had to define a dispatcher which consist of a single switch statement. It also brought an restriction what the driver can do. For example, we cannot add undefined symbols before any files are added to the symbol table. That's because no symbols can be added until the symbol table knows the ELF type, but when it knows about that, it's too late. In this patch, the driver makes a decision on what ELF type objects are being handled. Then the driver creates a SymbolTable object for an appropriate ELF type. http://reviews.llvm.org/D13544 llvm-svn: 249902
2015-10-10 05:07:25 +08:00
// RUN: llvm-mc -filetype=obj -triple=x86_64-pc-linux %s -o %t.o
[lld] Make tests calling llvm-ar more robust Some lit tests that call llvm-ar use the 'r' flag. If the target archive already exists and is in a corrupt state, this can cause the test to fail. We have added 'rm -f' calls before the llvm-ar calls to increase the robustness of the tests. Differential revision: https://reviews.llvm.org/D49184 llvm-svn: 338705
2018-08-02 19:33:54 +08:00
// RUN: rm -f %t.a
ELF2: Make SymbolTable a template class. SymbolTable was not a template class. Instead we had switch-case-based type dispatch to call desired functions. We had to do that because SymbolTable was created before we know what ELF type objects had been passed. Every time I tried to add a new function to the symbol table, I had to define a dispatcher which consist of a single switch statement. It also brought an restriction what the driver can do. For example, we cannot add undefined symbols before any files are added to the symbol table. That's because no symbols can be added until the symbol table knows the ELF type, but when it knows about that, it's too late. In this patch, the driver makes a decision on what ELF type objects are being handled. Then the driver creates a SymbolTable object for an appropriate ELF type. http://reviews.llvm.org/D13544 llvm-svn: 249902
2015-10-10 05:07:25 +08:00
// RUN: llvm-ar rcs %t.a %t.o
[ELF] Replace unused output filenames with /dev/null in tests Post commit review at rLLD335992 llvm-svn: 336129
2018-07-03 01:48:23 +08:00
// RUN: not ld.lld -o /dev/null -u _start %t.a 2>&1 | FileCheck %s
ELF2: Make SymbolTable a template class. SymbolTable was not a template class. Instead we had switch-case-based type dispatch to call desired functions. We had to do that because SymbolTable was created before we know what ELF type objects had been passed. Every time I tried to add a new function to the symbol table, I had to define a dispatcher which consist of a single switch statement. It also brought an restriction what the driver can do. For example, we cannot add undefined symbols before any files are added to the symbol table. That's because no symbols can be added until the symbol table knows the ELF type, but when it knows about that, it's too late. In this patch, the driver makes a decision on what ELF type objects are being handled. Then the driver creates a SymbolTable object for an appropriate ELF type. http://reviews.llvm.org/D13544 llvm-svn: 249902
2015-10-10 05:07:25 +08:00
ELF: clarify error when we don't know the output format lld differs from GNU ld in that it does not have a built-in default target emulation. Emulation is always specified via the -m option, or obtained from the object file(s) being linked. In most cases at least one ELF object is included in the link, so the emulation is known. When using lld's (not yet committed) -b binary support with -r, to convert a binary file into an ELF object we do not have a known emulation. The error message previously emitted in this case "-m or at least a .o file required" is accurate but does not offer much insight. Add text to the error message to give a hint why -m or an object file is required. Differential Revision: https://reviews.llvm.org/D24348 llvm-svn: 280989
2016-09-09 05:06:29 +08:00
// CHECK: target emulation unknown: -m or at least one .o file required
ELF2: Make SymbolTable a template class. SymbolTable was not a template class. Instead we had switch-case-based type dispatch to call desired functions. We had to do that because SymbolTable was created before we know what ELF type objects had been passed. Every time I tried to add a new function to the symbol table, I had to define a dispatcher which consist of a single switch statement. It also brought an restriction what the driver can do. For example, we cannot add undefined symbols before any files are added to the symbol table. That's because no symbols can be added until the symbol table knows the ELF type, but when it knows about that, it's too late. In this patch, the driver makes a decision on what ELF type objects are being handled. Then the driver creates a SymbolTable object for an appropriate ELF type. http://reviews.llvm.org/D13544 llvm-svn: 249902
2015-10-10 05:07:25 +08:00
.global _start
_start: