mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-12-12 22:17:47 +00:00
lld-link: Reject more than one resource .obj file
Users are exepcted to pass all .res files to the linker, which then merges all the resource in all .res files into a tree structure and then converts the final tree structure to a .obj file with .rsrc$01 and .rsrc$02 sections and then links that. If the user instead passes several .obj files containing such resources, the correct thing to do would be to have custom code to merge the trees in the resource sections instead of doing normal section merging -- but link.exe rejects if multiple resource obj files are passed in with LNK4078, so let lld-link do that too instead of silently writing broken .rsrc sections in that case. The only real way to run into this is if users manually convert .res files to .obj files by running cvtres and then handing the resulting .obj files to lld-link instead, which in practice likely never happens. (lld-link is slightly stricter than link.exe now: If link.exe is passed one .obj file created by cvtres, and a .res file, for some reason it just emits a warning instead of an error and outputs strange looking data. lld-link now errors out on mixed input like this.) One way users could accidentally run into this is the following scenario: If a .res file is passed to lib.exe, then lib.exe calls cvtres.exe on the .res file before putting it in the output .lib. (llvm-lib currently doesn't do this.) link.exe's /wholearchive seems to only add obj files referenced from the static library index, but lld-link current really adds all files in the archive. So if lld-link /wholearchive is used with .lib files produced by lib.exe and .res files were among the files handed to lib.exe, we previously silently produced invalid output, but now we error out. link.exe's /wholearchive semantics on the other hand mean that it wouldn't load the resource object files from the .lib file at all. Since this scenario is probably still an unlikely corner case, the difference in behavior here seems fine -- and lld-link might have to change to use link.exe's /wholearchive semantics in the future anyways. Vaguely related to PR42180. Differential Revision: https://reviews.llvm.org/D63109 llvm-svn: 363078
This commit is contained in:
parent
6e876b8416
commit
1aeeff713a
@ -442,7 +442,8 @@ WindowsResourceCOFFWriter::WindowsResourceCOFFWriter(
|
||||
Data(Parser.getData()), StringTable(Parser.getStringTable()) {
|
||||
performFileLayout();
|
||||
|
||||
OutputBuffer = WritableMemoryBuffer::getNewMemBuffer(FileSize);
|
||||
OutputBuffer = WritableMemoryBuffer::getNewMemBuffer(
|
||||
FileSize, "internal .obj file created from .res files");
|
||||
}
|
||||
|
||||
void WindowsResourceCOFFWriter::performFileLayout() {
|
||||
@ -521,7 +522,7 @@ void WindowsResourceCOFFWriter::writeCOFFHeader(uint32_t TimeDateStamp) {
|
||||
Header->NumberOfSections = 2;
|
||||
Header->TimeDateStamp = TimeDateStamp;
|
||||
Header->PointerToSymbolTable = SymbolTableOffset;
|
||||
// One symbol for every resource plus 2 for each section and @feat.00
|
||||
// One symbol for every resource plus 2 for each section and 1 for @feat.00
|
||||
Header->NumberOfSymbols = Data.size() + 5;
|
||||
Header->SizeOfOptionalHeader = 0;
|
||||
// cvtres.exe sets 32BIT_MACHINE even for 64-bit machine types. Match it.
|
||||
|
@ -82,6 +82,7 @@ group("test") {
|
||||
"//llvm/tools/llvm-ar:symlinks",
|
||||
"//llvm/tools/llvm-as",
|
||||
"//llvm/tools/llvm-bcanalyzer",
|
||||
"//llvm/tools/llvm-cvtres",
|
||||
"//llvm/tools/llvm-dis",
|
||||
"//llvm/tools/llvm-dwarfdump",
|
||||
"//llvm/tools/llvm-mc",
|
||||
|
Loading…
Reference in New Issue
Block a user