Closed Quuxplusone closed 10 years ago
Bugzilla Link | PR17595 |
Status | RESOLVED FIXED |
Importance | P normal |
Reported by | octoploid (octoploid@yandex.com) |
Reported on | 2013-10-16 03:07:21 -0700 |
Last modified on | 2013-10-16 07:48:31 -0700 |
Version | trunk |
Hardware | PC Linux |
CC | isanbard@gmail.com, llvm-bugs@lists.llvm.org, rafael@espindo.la |
Fixed by commit(s) | |
Attachments | |
Blocks | |
Blocked by | |
See also |
This might help find the problem:
Committing to https://llvm.org/svn/llvm-project/llvm/trunk ...
M include/llvm/Linker.h
M lib/LTO/LTOCodeGenerator.cpp
M lib/Linker/LinkModules.cpp
Committed r192778
M include/llvm/Linker.h
M lib/LTO/LTOCodeGenerator.cpp
M lib/Linker/LinkModules.cpp
r192778 = 051fa76ed98dd1b04e1819d21036e5bd3c8803c4 (refs/remotes/origin/master)
No changes between 5176cffb1ab3a1d015608a7c13c1d9c7ded9602f and
refs/remotes/origin/master
Resetting to the latest refs/remotes/origin/master
The problem seems to be that lto_codegen_dispose(code_gen) is
called a little too early.
The following patch fixes the issue for me:
diff --git a/tools/gold/gold-plugin.cpp b/tools/gold/gold-plugin.cpp
index 119631cfa7e0..16fadf9ee431 100644
--- a/tools/gold/gold-plugin.cpp
+++ b/tools/gold/gold-plugin.cpp
@@ -432,7 +432,6 @@ static ld_plugin_status all_symbols_read_hook(void) {
(*message)(LDPL_ERROR, "Could not produce a combined object file\n");
}
- lto_codegen_dispose(code_gen);
for (std::list<claimed_file>::iterator I = Modules.begin(),
E = Modules.end(); I != E; ++I) {
for (unsigned i = 0; i != I->syms.size(); ++i) {
@@ -444,18 +443,22 @@ static ld_plugin_status all_symbols_read_hook(void) {
if ((*add_input_file)(objPath) != LDPS_OK) {
(*message)(LDPL_ERROR, "Unable to add .o file to the link.");
(*message)(LDPL_ERROR, "File left behind in: %s", objPath);
+ lto_codegen_dispose(code_gen);
return LDPS_ERR;
}
if (!options::extra_library_path.empty() &&
set_extra_library_path(options::extra_library_path.c_str()) != LDPS_OK) {
(*message)(LDPL_ERROR, "Unable to set the extra library path.");
+ lto_codegen_dispose(code_gen);
return LDPS_ERR;
}
if (options::obj_path.empty())
Cleanup.push_back(objPath);
+ lto_codegen_dispose(code_gen);
+
return LDPS_OK;
}
I will take a look. I assume this reproduces with any binary, correct?
(In reply to comment #3)
> I will take a look. I assume this reproduces with any binary, correct?
Yes.
Thanks.
Fixed in r192787.
I went with copying the path to a std::string instead of delaying the call to lto_codegen_dispose.
Thanks for the bug report and patch!