thr3ads.net - llvm dev - [llvm-dev] How to debug if LTO generate wrong code? [May 2016]

If this information is useful, please help other people find it:
Share via:

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

head link

[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

head link

[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

Search for more possibly parallel threads

llvm dev - May 2016 - How to debug if LTO generate wrong code?

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

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

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

Possibly Parallel Threads