I don't think just use gold-plugin even modified is enough for the task
of building a whole-program bc file.
When we want to build a whole-program bc file by a general solution(I
meant that we can use such a method for all kinds of build system),we
need not only a gold-plugin to do what llvm-ld does,but also some
mechanisms,not a simple trick to modify the env variables,to run
ar,ld,ranlib's llvm-counterparts when building.
A wrapper which can wraps cc1,ld,ar,ranlib may archieve it..
I don't think just use gold-plugin even modified is enough for the task
of building a whole-program bc file.
When we want to build a whole-program bc file by a general solution(I
meant that we can use such a method for all kinds of build system),we
need not only a gold-plugin to do what llvm-ld does,but also some
mechanisms,not a simple trick to modify the env variables,to run
ar,ld,ranlib's llvm-counterparts when building.
Binutils 2.20 supports plugins and 'ar' and 'nm' will work with the gold plugin. Not sure about ranlib.
Thank you for the reply,but I meant that when we building,we can not use
the native tools such ar and as to process the llvm files,we must have
the ability to call llvm-ar and llvm-as instead of the native ones.
We can use the native tools if they understand llvm IL
That is what the plugin does. With it installed you can run nm in a
file with LLVM IL and it will print you the symbols. You can also add
IL files to an archive and the archive will have a correct symbol
table.
Yes,but when I just simply replace lto_codegen_compile(cg, ...) with
lto_codegen_write_merged_modules(cg, "/path/to/output.bc") in the
gold-plugin.cpp to see if it will generate a correct bc file,the
llvm-gcc/llvm-g++ will call the native ld in the linking step,which
causes the failture because of that ld can not recognize an object file
which contains LLVM's IL.
I understand the failture as this: libLLVMgold.so is just a plugin for
ld but not llvm-ld,when I want to build a whole-program bitcodes,llvm-ld
is the only available tool,so I think gold-plugin is not very useful to
archieve the goal,I'm considering to modify the codes of llvm-gcc's
collect2 to make it call llvm-ld automatically when receive certain
options.
Yes,but when I just simply replace lto_codegen_compile(cg, ...) with
lto_codegen_write_merged_modules(cg, "/path/to/output.bc") in the
gold-plugin.cpp to see if it will generate a correct bc file,the
llvm-gcc/llvm-g++ will call the native ld in the linking step,which
causes the failture because of that ld can not recognize an object file
which contains LLVM's IL.
The plugin is running *in* the native linker. What you want to do is
add an option in the plugin to write the bc file to an specified file
*in addition* to producing a regular elf object. This way the build
will complete correctly and you will get the .bc file you want.
I understand the failture as this: libLLVMgold.so is just a plugin for
ld but not llvm-ld,when I want to build a whole-program bitcodes,llvm-ld
is the only available tool,so I think gold-plugin is not very useful to
archieve the goal,I'm considering to modify the codes of llvm-gcc's
collect2 to make it call llvm-ld automatically when receive certain
options.
It will probably be hard to get this to work correctly with archives
and shared libraries. In 4.5 gcc we have a hacked collect2 for
people using lto and gnu ld.
