From cfe-users at lists.llvm.org Wed May 5 11:52:45 2021 From: cfe-users at lists.llvm.org (Richard Smith via cfe-users) Date: Wed, 5 May 2021 11:52:45 -0700 Subject: [cfe-users] How to find the physical end of an expression? In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 at 13:53, Taylor, Max via cfe-users < cfe-users at lists.llvm.org> wrote: > Greetings. > > > > I’m building a source-to-source tool with clang. What I want to do is > instrument stores made with the binary = operator. Currently, I’m running > into problems with rewriting expressions that contain macro invocations. > I’ve done some digging around, and I found some info that helped with my > understanding (e.g. > https://stackoverflow.com/questions/24062989/clang-fails-replacing-a-statement-if-it-contains-a-macro). > But I’m still not sure how to solve this problem. > > > > Concretely, suppose you have: > > #define a(x) ((x) * 10 + 1) > > > > class my_class { > > int x; > > > > public: > > int my_function() { > > x = a(0); > > return x; > > } > > }; > > > > I want to rewrite this into something like this: > > #ifndef _instrument_noclash > > #define _instrument_noclash(name, expr, instance_no) > \ > > (*({ > \ > > typeof(expr) *_t_instrument_no_clash##instance_no = &(expr); > \ > > _t_instrument_no_clash##instance_no; > \ > > })) > > #endif > > > > #define a(x) ((x) * 10 + 1) > > > > class my_class { > > int x; > > public: > > int my_function() { > > _instrument_noclash("x",(this->x=((0) * 10 + 1)),0); > > return x; > > } > > }; > > > > The problem (to me) is simple: *how do I determine the physical location > of the ending of the expression on the right hand sign of the = operator? *Without > this knowledge, I end up overwriting the end of the statement. Scanning the > APIs, it seems like there isn’t a simple way to do this. I’ve tried several > ways to get the ending source location: > > 1. op->getEndLoc(), where op is an instance of BinaryOperator. This > doesn’t work, because the ending location in the AST is not the same as the > physical end location of the expression, due to macro expansion. > 2. sm.getSpellingLoc(op->getEndLoc()), where sm is the source manager. > This just returns op->getEndLoc(). > 3. sm.getExpansionLoc(op->getEndLoc()). This is close, but the > location returned is the end of the macro name, so the macro arguments are > not removed. > > sm.getExpansionRange(op->getEndLoc()).getEnd() should work in this case. In general what you're trying to do is not possible, because the assignment expression might end in the middle of the macro expansion, though; depending on exactly what your goal is, it might be easiest to first preprocess the source file and then run your transform. > Any suggestions (or easier way to achieve this same goal) are appreciated. > > > > -Max > _______________________________________________ > cfe-users mailing list > cfe-users at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfe-users at lists.llvm.org Tue May 11 04:44:55 2021 From: cfe-users at lists.llvm.org (Oliver Niebuhr via cfe-users) Date: Tue, 11 May 2021 13:44:55 +0200 Subject: [cfe-users] Shared Debug Build MSYS2 MinGW-w64 constant Link Error Message-ID: Hello. As Static Debug Builds only work with MSVC, I am forced to use Shared-Libs with GCC on MSYS2. The Problem is, it always Fails at this exact stage: FAILED: bin/BugpointPasses.dll cmd.exe /C "cd . && C:\Dev\msys64\mingw64\bin\g++.exe -Wa,-mbig-obj -Werror=date-time -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-class-memaccess -Wno-redundant-move -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment -fasynchronous-unwind-tables -finput-charset=utf-8 -fno-lto -fno-omit-frame-pointer -grecord-gcc-switches -pthread -Og -g1 -ggdb -pipe -Wall -Wl,-Og -Wl,--allow-multiple-definition -Wl,--build-id=sha1 -Wl,--dynamicbase -Wl,--enable-auto-image-base -Wl,-fno-lto -Wl,--high-entropy-va -Wl,--nxcompat -Wa,-mbig-obj -Wl,-Bdynamic C:/Dev/Builds/LLVMx64DebugSrc/tools/bugpoint-passes/BugpointPasses.def -shared -o bin\BugpointPasses.dll -Wl,--major-image-version,0,--minor-image-version,0 tools/bugpoint-passes/CMakeFiles/BugpointPasses.dir/TestPasses.cpp.obj lib/libLLVMCore.dll.a -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && cd ." C:/Dev/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: tools/bugpoint-passes/CMakeFiles/BugpointPasses.dir/TestPasses.cpp.obj: in function `llvm::CallBase::getNumSubclassExtraOperands() const': C:/Dev/GitRepos/llvm-project/llvm/include/llvm/IR/InstrTypes.h:1198: undefined reference to `llvm::llvm_unreachable_internal(char const*, char const*, unsigned int)' collect2.exe: error: ld returned 1 exit status Sys Config: * Windows 10 21H1, x86_64 * MSYS2, MinGW-w64, 10.3.0, x86_64 * CMake 3.20.2 MinGW-w64 prebuilt, x86_64 * Ninja 1.10.2 MinGW-w64 prebuilt, x86_64 * LLVM 12.x Git Source * Building from MSYS2 MinGW64 Shell * Static Release Builds of LLVM/Clang for x86 and x86_64 are working just fine Latest CMake Config Flags tested: cmake ${SYSTEMDRIVE}/Dev/GitRepos/llvm-project/llvm/ ${SYSTEMDRIVE}/Dev/Builds/LLVMx64DebugSrc/ -G'Ninja' -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_C_FLAGS_DEBUG='-fasynchronous-unwind-tables -finput-charset=utf-8 -fno-lto -fno-omit-frame-pointer -grecord-gcc-switches -pthread -Og -g1 -ggdb -pipe -Wall -Wl,-Og -Wl,--allow-multiple-definition -Wl,--build-id=sha1-Wl,--dynamicbase -Wl,--enable-auto-image-base -Wl,-fno-lto -Wl,--high-entropy-va -Wl,--nxcompat -Wa,-mbig-obj -Wl,-Bdynamic' -DCMAKE_CXX_FLAGS_DEBUG='-fasynchronous-unwind-tables -finput-charset=utf-8 -fno-lto -fno-omit-frame-pointer -grecord-gcc-switches -pthread -Og -g1 -ggdb -pipe -Wall -Wl,-Og -Wl,--allow-multiple-definition -Wl,--build-id=sha1 -Wl,--default-image-base-high -Wl,--dynamicbase -Wl,--enable-auto-image-base -Wl,-fno-lto -Wl,--high-entropy-va -Wl,--nxcompat -Wa,-mbig-obj -Wl,-Bdynamic' -DLLVM_ENABLE_PROJECTS='clang;clang-tools-extra;compiler-rt;lld;lldb;llvm' -DCMAKE_CXX_STANDARD=17 -DCMAKE_INSTALL_PREFIX=${SYSTEMDRIVE}/Dev/Binaries/LLVMx64Debug/ -DCMAKE_BUILD_TYPE='Debug' -DLLVM_TARGETS_TO_BUILD='X86' -DBUILD_SHARED_LIBS='ON' -DLLVM_INCLUDE_EXAMPLES='OFF' -DLLVM_INCLUDE_TESTS='OFF' -DLLVM_INCLUDE_DOCS='OFF' -DLLVM_PARALLEL_COMPILE_JOBS=$(nproc) -DLLVM_PARALLEL_LINK_JOBS=$(nproc) -DLLVM_ENABLE_EH='OFF' -DLLVM_ENABLE_RTTI='OFF' -DLLVM_ENABLE_DIA_SDK='OFF' But that does only partially matter(?), because even with the DEFAULT FLAGS IT FAILS at this stage. So it seems I am missing something else. Another Compiler Flag? Another Linker Flag? General incompatibility? Thanks in advance! Olli From cfe-users at lists.llvm.org Tue May 11 19:59:42 2021 From: cfe-users at lists.llvm.org (Ni, Ray via cfe-users) Date: Wed, 12 May 2021 02:59:42 +0000 Subject: [cfe-users] Issue when clang launches "ld.lld.exe" in Windows OS through "-fuse-ld=ld.lld" Message-ID: Dear clang experts, I want to build out ELF image using clang in Windows OS. But I met an issue when using "-fuse-ld=ld.lld" to ask clang launch ld.lld.exe as a linker. Somehow clang always passes additional parameter to ld.lld: "-libpath:E:\\bin\\LLVM\\lib\\clang\\12.0.0\\lib\\windows" -nologo I found this behavior when I pass "-v" to clang. With "-v", clang will output the complete command line about how ld.lld is invoked. Command as below: "E:\bin\LLVM\bin\clang" -o e:\work\edk2\Build\UefiPayloadPkgX64\DEBUG_CLANGDWARF\IA32\UefiPayloadPkg\UefiPayloadEntry\UniversalPayloadEntry\DEBUG\UniversalPayloadEntry.elf -nostdlib -Wl,-n,-q,--gc-sections -z common-page-size=0x40 -Wl,--entry,_ModuleEntryPoint -u _ModuleEntryPoint -Wl,-Map,e:\work\edk2\Build\UefiPayloadPkgX64\DEBUG_CLANGDWARF\IA32\UefiPayloadPkg\UefiPayloadEntry\UniversalPayloadEntry\DEBUG/UniversalPayloadEntry.map,--whole-archive -fuse-ld=ld.lld -flto -Wl,-melf_i386 -Wl,--format=elf @e:\work\edk2\Build\UefiPayloadPkgX64\DEBUG_CLANGDWARF\IA32\UefiPayloadPkg\UefiPayloadEntry\UniversalPayloadEntry\OUTPUT\static_library_files.lst -v clang version 12.0.0 Target: x86_64-pc-windows-msvc Thread model: posix InstalledDir: E:\bin\LLVM\bin clang: warning: argument unused during compilation: '-u _ModuleEntryPoint' [-Wunused-command-line-argument] "E:\\bin\\LLVM\\bin\\ld.lld" "-out:e:\\work\\edk2\\Build\\UefiPayloadPkgX64\\DEBUG_CLANGDWARF\\IA32\\UefiPayloadPkg\\UefiPayloadEntry\\UniversalPayloadEntry\\DEBUG\\UniversalPayloadEntry.elf" "-libpath:E:\\bin\\LLVM\\lib\\clang\\12.0.0\\lib\\windows" -nologo -n -q --gc-sections common-page-size=0x40 --entry _ModuleEntryPoint -Map "e:\\work\\edk2\\Build\\UefiPayloadPkgX64\\DEBUG_CLANGDWARF\\IA32\\UefiPayloadPkg\\UefiPayloadEntry\\UniversalPayloadEntry\\DEBUG/UniversalPayloadEntry.map" --whole-archive -melf_i386 --format=elf e:/work/edk2/Build/UefiPayloadPkgX64/DEBUG_CLANGDWARF/IA32/MdePkg/Library/BasePcdLibNull/BasePcdLibNull/OUTPUT/BasePcdLibNull.lib e:/work/edk2/Build/UefiPayloadPkgX64/DEBUG_CLANGDWARF/IA32/MdePkg/Library/RegisterFilterLibNull/RegisterFilterLibNull/OUTPUT/FilterLibNull.lib e:/work/edk2/Build/UefiPayloadPkgX64/DEBUG_CLANGDWARF/IA32/MdePkg/Library/BaseLib/BaseLib/OUTPUT/BaseLib.lib e:/work/edk2/Build/UefiPayloadPkgX64/DEBUG_CLANGDWARF/IA32/MdePkg/Library/BaseMemoryLibRepStr/BaseMemoryLibRepStr/OUTPUT/BaseMemoryLibRepStr.lib e:/work/edk2/Build/UefiPayloadPkgX64/DEBUG_CLANGDWARF/IA32/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic/OUTPUT/BaseIoLibIntrinsic.lib e:/work/edk2/Build/UefiPayloadPkgX64/DEBUG_CLANGDWARF/IA32/MdePkg/Library/BasePciExpressLib/BasePciExpressLib/OUTPUT/BasePciExpressLib.lib e:/work/edk2/Build/UefiPayloadPkgX64/DEBUG_CLANGDWARF/IA32/UefiPayloadPkg/Library/DxeHobListLibNull/DxeHobListLibNull/OUTPUT/DxeHobListLibNull.lib e:/work/edk2/Build/UefiPayloadPkgX64/DEBUG_CLANGDWARF/IA32/UefiPayloadPkg/Library/PayloadEntryHobLib/HobLib/OUTPUT/HobLib.lib e:/work/edk2/Build/UefiPayloadPkgX64/DEBUG_CLANGDWARF/IA32/MdePkg/Library/BasePciLibPciExpress/BasePciLibPciExpress/OUTPUT/BasePciLibPciExpress.lib e:/work/edk2/Build/UefiPayloadPkgX64/DEBUG_CLANGDWARF/IA32/UefiPayloadPkg/Library/UniversalPayloadPlatformHookLib/PlatformHookLib/OUTPUT/PlatformHookLib.lib e:/work/edk2/Build/UefiPayloadPkgX64/DEBUG_CLANGDWARF/IA32/MdePkg/Library/BaseDebugPrintErrorLevelLib/BaseDebugPrintErrorLevelLib/OUTPUT/BaseDebugPrintErrorLevelLib.lib e:/work/edk2/Build/UefiPayloadPkgX64/DEBUG_CLANGDWARF/IA32/MdePkg/Library/BasePrintLib/BasePrintLib/OUTPUT/BasePrintLib.lib e:/work/edk2/Build/UefiPayloadPkgX64/DEBUG_CLANGDWARF/IA32/MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550/OUTPUT/BaseSerialPortLib16550.lib e:/work/edk2/Build/UefiPayloadPkgX64/DEBUG_CLANGDWARF/IA32/MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort/OUTPUT/BaseDebugLibSerialPort.lib e:/work/edk2/Build/UefiPayloadPkgX64/DEBUG_CLANGDWARF/IA32/MdePkg/Library/BasePeCoffExtraActionLibNull/BasePeCoffExtraActionLibNull/OUTPUT/PeCoffExtraActionLibNull.lib e:/work/edk2/Build/UefiPayloadPkgX64/DEBUG_CLANGDWARF/IA32/MdePkg/Library/BasePeCoffLib/BasePeCoffLib/OUTPUT/BasePeCoffLib.lib e:/work/edk2/Build/UefiPayloadPkgX64/DEBUG_CLANGDWARF/IA32/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib/OUTPUT/BaseUefiCpuLib.lib e:/work/edk2/Build/UefiPayloadPkgX64/DEBUG_CLANGDWARF/IA32/UefiPayloadPkg/UefiPayloadEntry/UniversalPayloadEntry/OUTPUT/UniversalPayloadEntry.lib ld.lld: error: unknown argument '-nologo' ld.lld: error: unable to find library -libpath:E:\bin\LLVM\lib\clang\12.0.0\lib\windows ld.lld: error: cannot open common-page-size=0x40: no such file or directory clang: error: linker command failed with exit code 1 (use -v to see invocation) Thanks, Ray -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfe-users at lists.llvm.org Thu May 20 12:18:10 2021 From: cfe-users at lists.llvm.org (Bella V via cfe-users) Date: Thu, 20 May 2021 12:18:10 -0700 Subject: [cfe-users] fetch variable names through debugInfo attached to load instructors Message-ID: Hello All, I read the documentation and I was able to fetch the variable names and source locations attached to metadata for call instructions (@llvm.dbg.declare) using dyn_cast. I wanted to check if we could fetch the variable names in the load/gep instructors using debugInfo. I want to collect the use variable object details within the function. I could only fetch the source locations (not the variable names) using !dbg attached to the load instructions. Any pointers if that is allowed. *C code:* int foo (bar_t *b, int len) { if (b == (bar_t *)NULL) { return 0; } return -1; } *IR optimised code through LTO:* ; Function Attrs: noinline nounwind optnone uwtable define i32 @foo(%struct.bar_t*, i32) #0 !dbg !10 { %3 = load i64, i64* getelementptr inbounds ([1 x i64], [1 x i64] %4 = add i64 %3, 1 %5 = alloca i32, align 4 %6 = alloca % struct.bar_t*, align 8 %7 = alloca i32, align 4 store % struct.bar_t* %0, % struct.bar_t** %6, align 8 call void @llvm.dbg.declare(metadata % struct.bar_t** %6, metadata !11, metadata !DIExpression()), !dbg !12 store i32 %1, i32* %7, align 4 call void @llvm.dbg.declare(metadata i32* %7, metadata !12, metadata !DIExpression()), !dbg !14 %8 = load % struct.bar_t*, % struct.bar_t** %6, align 8, !dbg !15 %9 = icmp eq % struct.bar_t* %8, null, !dbg !16 br i1 %9, label %10, label %11, !dbg !17 Many Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfe-users at lists.llvm.org Thu May 20 12:25:00 2021 From: cfe-users at lists.llvm.org (David Blaikie via cfe-users) Date: Thu, 20 May 2021 12:25:00 -0700 Subject: [cfe-users] fetch variable names through debugInfo attached to load instructors In-Reply-To: References: Message-ID: You'd have to analyze the dbg.declares and track that they refer to the same thing as the geps/loads you're interested in - from the dbg.declares (& dbg.values) you can follow those to find the variables they refer to. On Thu, May 20, 2021 at 12:18 PM Bella V via cfe-users < cfe-users at lists.llvm.org> wrote: > Hello All, > > I read the documentation and I was able to fetch the variable names and > source locations attached to metadata for call instructions > (@llvm.dbg.declare) using dyn_cast. I wanted to check > if we could fetch the variable names in the load/gep instructors using > debugInfo. I want to collect the use variable object details within the > function. > > > > I could only fetch the source locations (not the variable names) using > !dbg attached to the load instructions. Any pointers if that is allowed. > > > *C code:* > > int foo (bar_t *b, int len) > > { > > if (b == (bar_t *)NULL) { > > return 0; > > } > > return -1; > > } > > > > *IR optimised code through LTO:* > > ; Function Attrs: noinline nounwind optnone uwtable > > define i32 @foo(%struct.bar_t*, i32) #0 !dbg !10 { > > %3 = load i64, i64* getelementptr inbounds ([1 x i64], [1 x i64] > > %4 = add i64 %3, 1 > > %5 = alloca i32, align 4 > > %6 = alloca % struct.bar_t*, align 8 > > %7 = alloca i32, align 4 > > store % struct.bar_t* %0, % struct.bar_t** %6, align 8 > > call void @llvm.dbg.declare(metadata % struct.bar_t** %6, metadata !11, > metadata !DIExpression()), !dbg !12 > > store i32 %1, i32* %7, align 4 > > call void @llvm.dbg.declare(metadata i32* %7, metadata !12, metadata > !DIExpression()), !dbg !14 > > %8 = load % struct.bar_t*, % struct.bar_t** %6, align 8, !dbg !15 > > %9 = icmp eq % struct.bar_t* %8, null, !dbg !16 > > br i1 %9, label %10, label %11, !dbg !17 > > > > Many Thanks. > _______________________________________________ > cfe-users mailing list > cfe-users at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfe-users at lists.llvm.org Tue May 25 13:13:11 2021 From: cfe-users at lists.llvm.org (Bella V via cfe-users) Date: Tue, 25 May 2021 13:13:11 -0700 Subject: [cfe-users] fetch variable names through debugInfo attached to load instructors In-Reply-To: References: Message-ID: Thanks! It works. One sub-question: How do we analyze the member dereferenced struct variables as dbg.declares only has the declaration info as inside the function the struct variable types could have members dereferenced as well. Example: https://godbolt.org/z/zaeYn9do7 dbg.declares have use_var info, i would like to fetch address.id as well. On Thu, May 20, 2021 at 12:25 PM David Blaikie wrote: > You'd have to analyze the dbg.declares and track that they refer to the > same thing as the geps/loads you're interested in - from the dbg.declares > (& dbg.values) you can follow those to find the variables they refer to. > > On Thu, May 20, 2021 at 12:18 PM Bella V via cfe-users < > cfe-users at lists.llvm.org> wrote: > >> Hello All, >> >> I read the documentation and I was able to fetch the variable names and >> source locations attached to metadata for call instructions >> (@llvm.dbg.declare) using dyn_cast. I wanted to check >> if we could fetch the variable names in the load/gep instructors using >> debugInfo. I want to collect the use variable object details within the >> function. >> >> >> >> I could only fetch the source locations (not the variable names) using >> !dbg attached to the load instructions. Any pointers if that is allowed. >> >> >> *C code:* >> >> int foo (bar_t *b, int len) >> >> { >> >> if (b == (bar_t *)NULL) { >> >> return 0; >> >> } >> >> return -1; >> >> } >> >> >> >> *IR optimised code through LTO:* >> >> ; Function Attrs: noinline nounwind optnone uwtable >> >> define i32 @foo(%struct.bar_t*, i32) #0 !dbg !10 { >> >> %3 = load i64, i64* getelementptr inbounds ([1 x i64], [1 x i64] >> >> %4 = add i64 %3, 1 >> >> %5 = alloca i32, align 4 >> >> %6 = alloca % struct.bar_t*, align 8 >> >> %7 = alloca i32, align 4 >> >> store % struct.bar_t* %0, % struct.bar_t** %6, align 8 >> >> call void @llvm.dbg.declare(metadata % struct.bar_t** %6, metadata !11, >> metadata !DIExpression()), !dbg !12 >> >> store i32 %1, i32* %7, align 4 >> >> call void @llvm.dbg.declare(metadata i32* %7, metadata !12, metadata >> !DIExpression()), !dbg !14 >> >> %8 = load % struct.bar_t*, % struct.bar_t** %6, align 8, !dbg !15 >> >> %9 = icmp eq % struct.bar_t* %8, null, !dbg !16 >> >> br i1 %9, label %10, label %11, !dbg !17 >> >> >> >> Many Thanks. >> _______________________________________________ >> cfe-users mailing list >> cfe-users at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfe-users at lists.llvm.org Tue May 25 13:27:11 2021 From: cfe-users at lists.llvm.org (David Blaikie via cfe-users) Date: Tue, 25 May 2021 13:27:11 -0700 Subject: [cfe-users] fetch variable names through debugInfo attached to load instructors In-Reply-To: References: Message-ID: On Tue, May 25, 2021 at 1:13 PM Bella V wrote: > Thanks! It works. > > One sub-question: How do we analyze the member dereferenced struct > variables as dbg.declares only has the declaration info as inside the > function the struct variable types could have members dereferenced as well. > > Example: > > https://godbolt.org/z/zaeYn9do7 > > dbg.declares have use_var info, i would like to fetch address.id as well. > You'd have to do some sort of alias analysis, I guess - seeing that the load is from a pointer derived from the pointer that the alloca/dbg.declare describes - analyzing what offset from that is loaded, using the DI metadata to figure out which field that offset corresponds to. In general optimizations shouldn't try to do this - optimizations should be based on the IR alone, without attempting to be aware of the source constructs used to create them. For source analysis - the IR isn't a great tool for that, for the sort of reasons you're seeing here, and the analysis should probably be written in terms of Clang's AST instead. - Dave > > > On Thu, May 20, 2021 at 12:25 PM David Blaikie wrote: > >> You'd have to analyze the dbg.declares and track that they refer to the >> same thing as the geps/loads you're interested in - from the dbg.declares >> (& dbg.values) you can follow those to find the variables they refer to. >> >> On Thu, May 20, 2021 at 12:18 PM Bella V via cfe-users < >> cfe-users at lists.llvm.org> wrote: >> >>> Hello All, >>> >>> I read the documentation and I was able to fetch the variable names and >>> source locations attached to metadata for call instructions >>> (@llvm.dbg.declare) using dyn_cast. I wanted to check >>> if we could fetch the variable names in the load/gep instructors using >>> debugInfo. I want to collect the use variable object details within the >>> function. >>> >>> >>> >>> I could only fetch the source locations (not the variable names) using >>> !dbg attached to the load instructions. Any pointers if that is allowed. >>> >>> >>> *C code:* >>> >>> int foo (bar_t *b, int len) >>> >>> { >>> >>> if (b == (bar_t *)NULL) { >>> >>> return 0; >>> >>> } >>> >>> return -1; >>> >>> } >>> >>> >>> >>> *IR optimised code through LTO:* >>> >>> ; Function Attrs: noinline nounwind optnone uwtable >>> >>> define i32 @foo(%struct.bar_t*, i32) #0 !dbg !10 { >>> >>> %3 = load i64, i64* getelementptr inbounds ([1 x i64], [1 x i64] >>> >>> %4 = add i64 %3, 1 >>> >>> %5 = alloca i32, align 4 >>> >>> %6 = alloca % struct.bar_t*, align 8 >>> >>> %7 = alloca i32, align 4 >>> >>> store % struct.bar_t* %0, % struct.bar_t** %6, align 8 >>> >>> call void @llvm.dbg.declare(metadata % struct.bar_t** %6, metadata >>> !11, metadata !DIExpression()), !dbg !12 >>> >>> store i32 %1, i32* %7, align 4 >>> >>> call void @llvm.dbg.declare(metadata i32* %7, metadata !12, metadata >>> !DIExpression()), !dbg !14 >>> >>> %8 = load % struct.bar_t*, % struct.bar_t** %6, align 8, !dbg !15 >>> >>> %9 = icmp eq % struct.bar_t* %8, null, !dbg !16 >>> >>> br i1 %9, label %10, label %11, !dbg !17 >>> >>> >>> >>> Many Thanks. >>> _______________________________________________ >>> cfe-users mailing list >>> cfe-users at lists.llvm.org >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfe-users at lists.llvm.org Wed May 26 13:41:23 2021 From: cfe-users at lists.llvm.org (Bella V via cfe-users) Date: Wed, 26 May 2021 13:41:23 -0700 Subject: [cfe-users] getelementptr global type query Message-ID: Hello All, I'm not able to extract f1 from a getelementptr inbounds Instruction. struct foo { int num; }; extern struct foo f1; void hello () { if (f1.num){ } } @f1 = external dso_local global %struct.foo, align 4 define dso_local void @hello() #0 !dbg !9 { %1 = load i32, i32* getelementptr inbounds (%struct.foo, %struct.foo* *@f1* , i32 0, i32 0), align 4, !dbg !13 %2 = icmp ne i32 %1, 0, !dbg !15 br i1 %2, label %3, label %4, !dbg !16 } Instruction*Inst = load i32, i32* getelementptr inbounds (%struct.foo, %struct.foo* @f1, i32 0, i32 0) Value *V=Inst->getOperand()[0] = i32* getelementptr inbounds (%struct.foo, %struct.foo* @f1, i32 0, i32 0) *V->getName().str() *// does not return anything. Any pointers. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: