I didn't try to compile it locally (I don't have/use gold), but you should be able to fix the 3 errors fairly easily (looks like missing includes mostly).
We don't use cl::opt in gold, instead we parse the -plugin-opts that
gold passes the plugin (see process_plugin_option).
Cheers,
Rafael
What about that:
$ grep ParseCommandLineOptions tools/gold/gold-plugin.cpp
// ParseCommandLineOptions() expects argv[0] to be program name. Lazily
cl::ParseCommandLineOptions(NumOpts, &options::extra[0]);
That is for the options that the gold plugin itself doesn't understand
and just passes to llvm. This allows you to do things like
--plugin-opt=-debug-pass=Arguments.
Cheers,
Rafael
We don't use cl::opt in gold, instead we parse the -plugin-opts that
gold passes the plugin (see process_plugin_option).What about that:
$ grep ParseCommandLineOptions tools/gold/gold-plugin.cpp
// ParseCommandLineOptions() expects argv[0] to be program name.
Lazilycl::ParseCommandLineOptions(NumOpts, &options::extra[0]);
That is for the options that the gold plugin itself doesn't understand
and just passes to llvm. This allows you to do things like
--plugin-opt=-debug-pass=Arguments.
This is what I expected, so my cl:opt should work, right? I don't really get your original point?
Mehdi
Just that the gold plugin itself never defines a cl::opt. It just
forwards the llvm ones.
Cheers,
Rafael
Hi Mehdi,
What's the default code model for x86_64 Mac OS X App? Andrew showed me some example code of Mac OS X App as below, which looks to use the small code model but can run at >4GB high address.
For example if you read a global like this the compiler will generate this code.
int constant = 0;
int get_constant(void)
{
return constant;
}
(lldb) dis -n get_constant -b
a.out`get_constant:
a.out[0x100000f8c] <+0>: 55 pushq %rbp
a.out[0x100000f8d] <+1>: 48 89 e5 movq %rsp, %rbp
a.out[0x100000f90] <+4>: 8b 05 6a 00 00 00 movl 0x6a(%rip), %eax
a.out[0x100000f96] <+10>: 5d popq %rbp
a.out[0x100000f97] <+11>: c3 retq
Steven Shi
Intel\SSG\STO\UEFI Firmware
Tel: +86 021-61166522
iNet: 821-6522
Hi Mehdi,
What's the default code model for x86_64 Mac OS X App? Andrew showed me some example code of Mac OS X App as below, which looks to use the small code model but can run at >4GB high address.
Small, but PIC.
For example if you read a global like this the compiler will generate this code.
int constant = 0;int get_constant(void)
{
return constant;
}
Compiling for ELF with -FPIE -Os I get
get_constant: # @get_constant
# BB#0: # %entry
movl constant(%rip), %eax
retq
Which should also be able to run at any address.
Cheers,
Rafael
OK, I get it. Adding "-pie" link option can force 64bits relocation address (e.g. EM_X86_64), instead of the 32bits one (e.g. R_X86_64_32S). I only used -fpic and -fpie in clang LTO compile option, and forgot add the "-pie" link option in ld. So my clang + ld LTO executable was still not position independent.
Thank you all!
Steven Shi
Intel\SSG\STO\UEFI Firmware
Tel: +86 021-61166522
iNet: 821-6522
Hi Rafael,
I finally enable the clang LTO build with small code model and PIE, and my clang LTO Uefi firmware works now. Thank you! But I have one more issue on the clang normal build (without LTO) now. I find the small code model + "-fpie" build option will let clang generate some R_X86_64_GOTPCREL type relocation entries in my firmware image, which not happen in the clang LTO build. I wish I could enforce the clang normal build not to use the R_X86_64_GOTPCREL relocation type but to use R_X86_64_PC32 or R_X86_64_PLT32 instead. How could I do it?
Steven Shi
Intel\SSG\STO\UEFI Firmware
Tel: +86 021-61166522
iNet: 821-6522
Does it reproduce with clang trunk?
Cheers,
Rafael
Yes. I use the trunk, and my version is below. I could try the latest version tomorrow. And if you need, I could give the reproduce build steps on my Uefi firmware tomorrow. Thank you!
clang version 3.9.0 (trunk 271203)
Steven Shi
Intel\SSG\STO\UEFI Firmware
Tel: +86 021-61166522
iNet: 821-6522