Shi, Steven via llvm-dev
2016-May-13 14:18 UTC
[llvm-dev] How to debug if LTO generate wrong code?
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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160513/cf7649a6/attachment.html>
Umesh Kalappa via llvm-dev
2016-May-13 18:14 UTC
[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> 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 > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >
Shi, Steven via llvm-dev
2016-May-16 14:39 UTC
[llvm-dev] How to debug if LTO generate wrong code?
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/llvm-dev/attachments/20160516/540e803b/attachment.html>
Possibly Parallel Threads
- How to debug if LTO generate wrong code?
- [cfe-dev] How to debug if LTO generate wrong code?
- How to debug if LTO generate wrong code?
- IRMover asserts "mapping to a source type" when repeatedly linking - usage or LLVM bug?
- How to flatten a tree (based on list) to a certain depth?