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

Umesh Kalappa via llvm-dev llvm-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 llvm-dev mailing list