llvm dev - Jun 2016 - [cfe-dev] How to debug if LTO generate wrong code?

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
> -----Original Message-----
> From: Rafael Espíndola [mailto:rafael.espindola at gmail.com]
> Sent: Tuesday, May 31, 2016 9:21 PM
> To: Shi, Steven <steven.shi at intel.com>
> Cc: Mehdi Amini <mehdi.amini at apple.com>; Umesh Kalappa
> <umesh.kalappa0 at gmail.com>; eliben at gmail.com; llvm-dev
<llvm-
> dev at lists.llvm.org>; cfe-dev at lists.llvm.org; afish at apple.com
> Subject: Re: [cfe-dev] [llvm-dev] How to debug if LTO generate wrong code?
> 
> On 31 May 2016 at 01:08, Shi, Steven <steven.shi at intel.com> wrote:
> > 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

On 7 June 2016 at 10:54, Shi, Steven <steven.shi at intel.com>
wrote:
> 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?
Does it reproduce with clang trunk?

Cheers,
Rafael