maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lld/test/core/undef-fallback.objtxt

38 lines
786 B
Plaintext
Raw Normal View History

Add a fallback mechanism for undefined atom. In COFF, an undefined symbol can have up to one alternative name. If a symbol is resolved by its regular name, then it's linked normally. If a symbol is not found in any input files, all references to the regular name are resolved using the alternative name. If the alternative name is not found, it's a link error. This mechanism is called "weak externals". To support this mechanism, I added a new member function fallback() to undefined atom. If an undefined atom has the second name, fallback() returns a new undefined atom that should be used instead of the original one to resolve undefines. If it does not have the second name, the function returns nullptr. Differential Revision: http://llvm-reviews.chandlerc.com/D1550 llvm-svn: 190625
2013-09-13 03:14:05 +08:00
# RUN: lld -core %s | FileCheck %s
# Test that fallback atoms can be parsed by YAML reader and processed by the
# core linker.
---
defined-atoms:
Fix Weak External symbol handling. The fallback atom was used only when it's searching for a symbol in a library; if an undefined symbol was not found in a library, the LLD looked for its fallback symbol in the library. Although it worked in most cases, because symbols with fallbacks usually occur only in OLDNAMES.LIB (a standard library), that behavior was incompatible with link.exe. This patch fixes the issue so that the semantics is the same as MSVC's link.exe The new (and correct, I believe) behavior is this: - If there's no definition for an undefined atom, replace the undefined atom with its fallback and then proceed (e.g. look in the next file or stop linking as usual.) Weak External symbols are underspecified in the Microsoft PE/COFF spec. However, as long as I observed the behavior of link.exe, this seems to be what we want for compatibility. Differential Revision: http://llvm-reviews.chandlerc.com/D2162 llvm-svn: 195269
2013-11-21 04:51:55 +08:00
- name: def1
scope: global
Add a fallback mechanism for undefined atom. In COFF, an undefined symbol can have up to one alternative name. If a symbol is resolved by its regular name, then it's linked normally. If a symbol is not found in any input files, all references to the regular name are resolved using the alternative name. If the alternative name is not found, it's a link error. This mechanism is called "weak externals". To support this mechanism, I added a new member function fallback() to undefined atom. If an undefined atom has the second name, fallback() returns a new undefined atom that should be used instead of the original one to resolve undefines. If it does not have the second name, the function returns nullptr. Differential Revision: http://llvm-reviews.chandlerc.com/D1550 llvm-svn: 190625
2013-09-13 03:14:05 +08:00
undefined-atoms:
Fix Weak External symbol handling. The fallback atom was used only when it's searching for a symbol in a library; if an undefined symbol was not found in a library, the LLD looked for its fallback symbol in the library. Although it worked in most cases, because symbols with fallbacks usually occur only in OLDNAMES.LIB (a standard library), that behavior was incompatible with link.exe. This patch fixes the issue so that the semantics is the same as MSVC's link.exe The new (and correct, I believe) behavior is this: - If there's no definition for an undefined atom, replace the undefined atom with its fallback and then proceed (e.g. look in the next file or stop linking as usual.) Weak External symbols are underspecified in the Microsoft PE/COFF spec. However, as long as I observed the behavior of link.exe, this seems to be what we want for compatibility. Differential Revision: http://llvm-reviews.chandlerc.com/D2162 llvm-svn: 195269
2013-11-21 04:51:55 +08:00
- name: undef1
Add a fallback mechanism for undefined atom. In COFF, an undefined symbol can have up to one alternative name. If a symbol is resolved by its regular name, then it's linked normally. If a symbol is not found in any input files, all references to the regular name are resolved using the alternative name. If the alternative name is not found, it's a link error. This mechanism is called "weak externals". To support this mechanism, I added a new member function fallback() to undefined atom. If an undefined atom has the second name, fallback() returns a new undefined atom that should be used instead of the original one to resolve undefines. If it does not have the second name, the function returns nullptr. Differential Revision: http://llvm-reviews.chandlerc.com/D1550 llvm-svn: 190625
2013-09-13 03:14:05 +08:00
fallback:
Fix Weak External symbol handling. The fallback atom was used only when it's searching for a symbol in a library; if an undefined symbol was not found in a library, the LLD looked for its fallback symbol in the library. Although it worked in most cases, because symbols with fallbacks usually occur only in OLDNAMES.LIB (a standard library), that behavior was incompatible with link.exe. This patch fixes the issue so that the semantics is the same as MSVC's link.exe The new (and correct, I believe) behavior is this: - If there's no definition for an undefined atom, replace the undefined atom with its fallback and then proceed (e.g. look in the next file or stop linking as usual.) Weak External symbols are underspecified in the Microsoft PE/COFF spec. However, as long as I observed the behavior of link.exe, this seems to be what we want for compatibility. Differential Revision: http://llvm-reviews.chandlerc.com/D2162 llvm-svn: 195269
2013-11-21 04:51:55 +08:00
name: fallback1
- name: undef2
fallback:
name: fallback2
---
defined-atoms:
- name: fallback1
undefined-atoms:
- name: def1
fallback:
name: fallback3
Add a fallback mechanism for undefined atom. In COFF, an undefined symbol can have up to one alternative name. If a symbol is resolved by its regular name, then it's linked normally. If a symbol is not found in any input files, all references to the regular name are resolved using the alternative name. If the alternative name is not found, it's a link error. This mechanism is called "weak externals". To support this mechanism, I added a new member function fallback() to undefined atom. If an undefined atom has the second name, fallback() returns a new undefined atom that should be used instead of the original one to resolve undefines. If it does not have the second name, the function returns nullptr. Differential Revision: http://llvm-reviews.chandlerc.com/D1550 llvm-svn: 190625
2013-09-13 03:14:05 +08:00
...
# CHECK: defined-atoms:
Fix Weak External symbol handling. The fallback atom was used only when it's searching for a symbol in a library; if an undefined symbol was not found in a library, the LLD looked for its fallback symbol in the library. Although it worked in most cases, because symbols with fallbacks usually occur only in OLDNAMES.LIB (a standard library), that behavior was incompatible with link.exe. This patch fixes the issue so that the semantics is the same as MSVC's link.exe The new (and correct, I believe) behavior is this: - If there's no definition for an undefined atom, replace the undefined atom with its fallback and then proceed (e.g. look in the next file or stop linking as usual.) Weak External symbols are underspecified in the Microsoft PE/COFF spec. However, as long as I observed the behavior of link.exe, this seems to be what we want for compatibility. Differential Revision: http://llvm-reviews.chandlerc.com/D2162 llvm-svn: 195269
2013-11-21 04:51:55 +08:00
# CHECK-NEXT: - name: def1
# CHECK-NEXT: scope: global
# CHECK-NEXT: - name: fallback1
# CHECK-NEXT: ref-name: fallback1
# CHECK-NEXT: undefined-atoms:
# CHECK-NEXT: - name: fallback1
# CHECK-NEXT: - name: fallback2
# CHECK-NOT: - name: fallback3