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

Shi, Steven via cfe-dev cfe-dev at lists.llvm.org
Mon May 16 07:39:41 PDT 2016


Hi Umesh,

Thank you for the suggestion. I can use the "Brute force method " to narrow down the LTO wrong instructions here and there, but I still don't know why these wrong instructions are generated, and how to let Clang LTO don't generate those wrong instructions.

I suspect the wrong code is caused by some LTO wrong optimization pass, so I hope to disable all optimizations in the LTO firstly, then enable them one by one later to narrow down my issue root cause. But when I try to disable the optimization by enforcing –O0 in the LTO build, I find the ld fails to recognize some clang  bitcode library, and fail to link.



e.g. use the Clang_LTO_Fails_On_LD example in below bug attachment

https://sourceware.org/bugzilla/show_bug.cgi?id=20070



If I enforce the -O0 to disable the optimization in LTO, the ld fail to link:

~/clang38/bin/clang -o Hello.dll -flto -O0 -nostdlib -Wl,-n -Wl,-q -Wl,--gc-sections -Wl,-z,common-page-size=0x40 -Wl,--entry,_ModuleEntryPoint -Wl,-u,_ModuleEntryPoint -Wl,-Map,Hello.map -Wl,-melf_x86_64 -Wl,--oformat=elf64-x86-64 -Wl,--start-group,, at static_library_files.lst -Wl,--end-group

BaseLib.lib: error adding symbols: File format not recognized

clang-3.8: error: linker command failed with exit code 1 (use -v to see invocation)



But if I enable the -O1, -O2, or higher -On, the ld  link pass:

~/clang38/bin/clang -o Hello.dll -flto -O1 -nostdlib -Wl,-n -Wl,-q -Wl,--gc-sections -Wl,-z,common-page-size=0x40 -Wl,--entry,_ModuleEntryPoint -Wl,-u,_ModuleEntryPoint -Wl,-Map,Hello.map -Wl,-melf_x86_64 -Wl,--oformat=elf64-x86-64 -Wl,--start-group,, at static_library_files.lst -Wl,--end-group





How can I correctly disable all the optimization in clang LTO? How can I know, enable and disable the specific optimizations in clang LTO? Any suggestion is welcomed!







Steven Shi

Intel\SSG\STO\UEFI Firmware



Tel: +86 021-61166522

iNet: 821-6522



> -----Original Message-----

> From: Umesh Kalappa [mailto:umesh.kalappa0 at gmail.com]

> Sent: Saturday, May 14, 2016 2:14 AM

> To: Shi, Steven <steven.shi at intel.com>

> Cc: llvm-dev <llvm-dev at lists.llvm.org>; cfe-dev at lists.llvm.org

> Subject: Re: [llvm-dev] How to debug if LTO generate wrong code?

>

> Steven,

>

> Brute force method  is ,get the disassemble of the hanged function and

> try to check the difference with and without LTO in the generated

> code.

>

> or try to attach gdb and check  for the instruction ,that cause the exception .

>

> Thank you

> ~Umesh

>

> On Fri, May 13, 2016 at 7:48 PM, Shi, Steven via llvm-dev

> <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:

> > Hello,

> >

> > I'm enabling clang LTO to improve code size of Uefi standard

> > (http://www.uefi.org/) firmware (https://github.com/tianocore/edk2),

> which

> > is mostly C code. My project is in https://github.com/shijunjing/edk2

> branch

> > llvm : https://github.com/shijunjing/edk2/tree/llvm. I find my most

> firmware

> > modules work well after enable LTO, but some X64 modules will not run

> (e.g.

> > hang with CPU exception) , and these X64 modules work well if build with

> the

> > LTO disabled (-fno-lto).

> >

> > I don’t know how to efficiently debug these LTO wrong code and

> investigate

> > if there is compiler’s bug. I appreciate if anyone can  give me some

> > suggestions about the clang LTO issue debug method, commands, or BKMs.

> >

> >

> >

> > Below are  my clang LTO build tools and options, I use clang 3.8 release

> > with binutils 2.26 ld (I’ve pushed ld support LLVM gold plugin

> > https://sourceware.org/bugzilla/show_bug.cgi?id=20070). Any suggestion

> is

> > welcome!

> >

> >

> >

> >

> >

> >

> >

> > ##################

> >

> > # CLANGLTO38 X64 definitions

> >

> > ##################

> >

> > *_CLANGLTO38_X64_OBJCOPY_PATH         =

> DEF(GCC53_X64_PREFIX)objcopy

> >

> > *_CLANGLTO38_X64_CC_PATH              = DEF(CLANG38_X64_PREFIX)clang

> >

> > *_CLANGLTO38_X64_SLINK_PATH           = DEF(CLANG38_X64_PREFIX)llvm-

> ar

> >

> > *_CLANGLTO38_X64_DLINK_PATH           =

> DEF(CLANG38_X64_PREFIX)clang

> >

> > *_CLANGLTO38_X64_ASM_PATH             = DEF(CLANG38_X64_PREFIX)clang

> >

> > *_CLANGLTO38_X64_PP_PATH              = DEF(CLANG38_X64_PREFIX)clang

> >

> > *_CLANGLTO38_X64_RC_PATH              = DEF(GCC53_X64_PREFIX)objcopy

> >

> >

> >

> > *_CLANGLTO38_X64_CC_FLAGS = -c -fshort-wchar -fno-strict-aliasing -

> Wall

> > -Werror -Wno-array-bounds -Wno-empty-body -ffunction-sections

> > -fdata-sections -include AutoGen.h -

> DSTRING_ARRAY_NAME=$(BASE_NAME)Strings

> > -fno-stack-protector -fno-builtin -mms-bitfields -Wno-address

> > -Wno-shift-negative-value -Wno-parentheses-equality -Wno-unknown-

> pragmas

> > -Wno-tautological-constant-out-of-range-compare

> > -Wno-incompatible-library-redeclaration -target x86_64-pc-linux-gnu

> > -fno-asynchronous-unwind-tables -m64 -Wno-enum-conversion

> > "-DEFIAPI=__attribute__((ms_abi))" -mno-red-zone -mcmodel=large -g -Os

> -flto

> >

> > *_CLANGLTO38_X64_DLINK_FLAGS  = -flto -nostdlib -Wl,-n -Wl,-q

> > -Wl,--gc-sections -Wl,-z,common-page-size=0x40

> > -Wl,--entry,$(IMAGE_ENTRY_POINT) -Wl,-u,$(IMAGE_ENTRY_POINT)

> > -Wl,-Map,$(DEST_DIR_DEBUG)/$(BASE_NAME).map -Wl,-melf_x86_64

> > -Wl,--oformat=elf64-x86-64

> >

> > *_CLANGLTO38_X64_ASM_FLAGS            = -c -x assembler -imacros

> > $(DEST_DIR_DEBUG)/AutoGen.h -m64 -target x86_64-pc-linux-gnu

> >

> > *_CLANGLTO38_X64_RC_FLAGS             = -I binary -O elf64-x86-64        -B

> > i386    --rename-section .data=.hii

> >

> > *_CLANGLTO38_X64_NASM_FLAGS           = -f elf64

> >

> >

> >

> >

> >

> >

> >

> > Steven Shi

> >

> > Intel\SSG\STO\UEFI Firmware

> >

> >

> >

> > Tel: +86 021-61166522

> >

> > iNet: 821-6522

> >

> >

> >

> >

> > _______________________________________________

> > LLVM Developers mailing list

> > llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>

> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160516/540e803b/attachment.html>


More information about the cfe-dev mailing list