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

[Shi, Steven via llvm-dev]

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


> -----Original Message-----
> From: Rafael Espíndola [mailto:rafael.espindola at gmail.com]
> Sent: Tuesday, June 07, 2016 11:05 PM
> To: Shi, Steven <steven.shi at intel.com>
> Cc: Mehdi Amini <mehdi.amini at apple.com>; Umesh Kalappa
> <umesh.kalappa0 at gmail.com>; llvm-dev <llvm-dev at lists.llvm.org>; cfe-
> dev at lists.llvm.org; afish at apple.com; Lu, Hongjiu <hongjiu.lu at intel.com>
> Subject: Re: [cfe-dev] [llvm-dev] How to debug if LTO generate wrong code?
> 
> 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