[cfe-dev] [llvm-dev] How to debug if LTO generate wrong code?
Umesh Kalappa via cfe-dev
cfe-dev at lists.llvm.org
Fri May 13 11:14:13 PDT 2016
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
>
More information about the cfe-dev
mailing list