search for: claim_file_hook

...; > Looking in /proc, it has 10013 open file descriptors. With only 2 objects loaded at a time, I'd expect many fewer file descriptors to be open. Maybe it only has 2 objects in memory at once but keeps all the file descriptors open? That is odd. I will debug it in a sec, but we have in the claim_file_hook: if (code_gen) { if (lto_codegen_add_module(code_gen, M)) { (*message)(LDPL_ERROR, "Error linking module: %s", lto_get_error_message()); return LDPS_ERR; } } lto_module_dispose(M); In fact, with current gold we call get_view, so the plugin use...

.../include/plugin-api.h:37:2: error: #error can not find uint64_t type In file included from gold-plugin.cpp:15: /home/lefever/work/llvm/v2.6/llvm-2.6_optimized/../gold-plugin/binutils/src/include/plugin-api.h:91: error: ‘uint64_t’ does not name a type gold-plugin.cpp: In function ‘ld_plugin_status claim_file_hook(const ld_plugin_input_file*, int*)’: gold-plugin.cpp:279: error: ‘struct ld_plugin_symbol’ has no member named ‘size’ make[2]: *** [/home/lefever/work/llvm/v2.6/llvm-2.6_optimized/tools/gold/Release/gold-plugin.o] Error 1 -------------------------- Thanks, Ryan

On Nov 14, 2013, at 8:19 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > But gold has at most 2 objects loaded at any time. Are you sure about that? I haven't looked into it but while building Chromium with LTO, I get: ../../third_party/gold/gold64: fatal error: out of file descriptors and couldn't close any clang: error: linker command failed with exit code 1

...king in /proc, it has 10013 open file descriptors. With only 2 objects loaded at a time, I'd expect many fewer file descriptors to be open. Maybe it only has 2 objects in memory at once but keeps all the file descriptors open? > > That is odd. I will debug it in a sec, but we have in the claim_file_hook: > > if (code_gen) { > if (lto_codegen_add_module(code_gen, M)) { > (*message)(LDPL_ERROR, "Error linking module: %s", > lto_get_error_message()); > return LDPS_ERR; > } > } > > lto_module_dispose(M); > > In fact, w...

...hard requirement for some cases. For example, currently I get the following valgrind error when doing LTO and fetching an archive member: at 0x6DAC36E: llvm::MemoryBuffer::init(char const*, char const*) (MemoryBuffer.cpp:50) Address 0x5fecea0 is 0 bytes after a block of size 464 alloc'd claim_file_hook(ld_plugin_input_file const*, int*) (gold-plugin.cpp:261) The memory access is the assert that the buffer is null terminated and the allocation is done to read in an archive member to pass to libLTO. I could fix this by just allocating one byte more, but I would like instead to mmap the archives...

...p +++ b/tools/gold/gold-plugin.cpp @@ -428,8 +428,6 @@ getMinVisibility(GlobalValue::VisibilityTypes A, return A; if (B == GlobalValue::HiddenVisibility) return B; - if (A == GlobalValue::ProtectedVisibility) - return A; return B; } @@ -520,15 +518,9 @@ static ld_plugin_status claim_file_hook(const ld_plugin_input_file *file, Res.IsLinkonceOdr &= GV->hasLinkOnceLinkage(); Res.Visibility = getMinVisibility(Res.Visibility, GV->getVisibility()); switch (GV->getVisibility()) { - case GlobalValue::DefaultVisibility: - sym.visibility = LDPV_DEFAUL...

.../proc, it has 10013 open file descriptors. With only 2 objects loaded at a time, I'd expect many fewer file descriptors to be open. Maybe it only has 2 objects in memory at once but keeps all the file descriptors open? >> >> That is odd. I will debug it in a sec, but we have in the claim_file_hook: >> >> if (code_gen) { >> if (lto_codegen_add_module(code_gen, M)) { >> (*message)(LDPL_ERROR, "Error linking module: %s", >> lto_get_error_message()); >> return LDPS_ERR; >> } >> } >> >> lto_mo...

Hello >           -c ../../llvm-gcc-4.8/gcc/crtstuff.c -DCRT_BEGIN \ >           -o crtbegin.o > C:/MinGW/llvm/arm_objects/gcc/as: line 2: exec: -o: invalid option You don't have cross ARM binutils installed. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

Hi,     I get the following error where the "make"(building) stops.   /MinGW/llvm/arm_objects/./gcc/xgcc -B/MinGW/llvm/arm_objects/./gcc/ -B/MinGW/llv m/arm_objects/../install/arm-linux/bin/ -B/MinGW/llvm/arm_objects/../install/arm -linux/lib/ -isystem /MinGW/llvm/arm_objects/../install/arm-linux/include -isyst em /MinGW/llvm/arm_objects/../install/arm-linux/sys-include  -O2 -O2 -g -O2 

...to `_lto_code gen_write_merged_modules' /llvm/llvm-src/tools/gold/gold-plugin.cpp:447: undefined reference to `_lto_code gen_compile' /llvm/llvm-src/tools/gold/gold-plugin.cpp:473: undefined reference to `_lto_code gen_dispose' /llvm/llvm-src/tools/gold/Debug/gold-plugin.o: In function `claim_file_hook': /llvm/llvm-src/tools/gold/gold-plugin.cpp:264: undefined reference to `_lto_modu le_is_object_file_in_memory' /llvm/llvm-src/tools/gold/gold-plugin.cpp:268: undefined reference to `_lto_modu le_is_object_file' /llvm/llvm-src/tools/gold/gold-plugin.cpp:276: undefined reference to `_lto...