similar to: LLVM IR with MakeFile

Hi David Thank you very much for your suggestions. ScopeLine works well. It could represent the start of a function. Do you know whether I can get the start column of this function? Many Thanks Regards Muhui 2018-05-30 3:25 GMT+08:00 David Blaikie <dblaikie at gmail.com>: > > > On Tue, May 29, 2018 at 5:25 AM Muhui Jiang via llvm-dev < > llvm-dev at lists.llvm.org>

On Tue, May 29, 2018 at 5:25 AM Muhui Jiang via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi > > I am using LLVM to help me do some code analysis. I wrote a LLVM Function > Pass to help me to generate some information. I use the code below to get > the source line information for every instruction. > > for (BasicBlock &BB : F){ > for(Instruction &I:

Hi I am using LLVM to help me do some code analysis. I wrote a LLVM Function Pass to help me to generate some information. I use the code below to get the source line information for every instruction. for (BasicBlock &BB : F){ for(Instruction &I: BB){ DILocation* Loc = I.getDebugLoc().get(); unsigned Line = Loc->getLine() } } I think the function's first

Hi Teresa Thanks for your very quick and clear explanation. I have one more question. The emit-llvm option will give you the IR for a single source file when you compile it with -c. All of those files when combined give the IR in the preopt.bc temp file. =========== So if I use "clang -emit-llvm -c" to generate the .ll file. It should be the same as the one I generated by using

These are the bitcode at different stages of the LTO portion of the compile. LTO merges the IR for all files being linked and optimizes them as a single monolithic module. The preopt.bc is the merged IR just after merging and before performing any LTO optimizations. internalize.bc is after performing whole program internalization. opt.bc is after the optimization pipeline, and .precodegen.bc is

Hi I use the LDFLAGS=" -flto -fuse-ld=gold -Wl,-plugin-opt=save-temps " to generate the makefile and to make the whole program. However, found four different kinds of bitcode for each target. For example, I am compiling coreutils. For the program "nohup", I can get nohup.0.0.preopt.bc nohup.0.2.internalize.bc nohup.0.4.opt.bc nohup.0.5.precodegen.bc If I am right, I

Hi However, frontend may also do various operations on the source code and one line number and column number could map to more than one binary address. Why LLVM IR cannot? Regrads Muhui 2018-06-12 23:18 GMT+08:00 mayuyu.io <admin at mayuyu.io>: > In theory that’s not exactly possible/accurate. Due to various operations > in the Backend like Instruction Legalization, one IR

Hi Paul Thanks for your comments. Suppose I can generate the control flow graph via LLVM Pass or the default option like '-dot-cfg' with opt. However, the control flow graph is based on llvm IR level. I would like to have a control flow graph based on binary level. Thus, I want to map the IR to binary address. As far as I know, we used to use the debug information to map the IR to source

Hi I know that LLVM provide some debug API for us to know the source code information. For example, every IR instruction's source line number and column number. However, are there any method to get a mapping from IR instruction to binary address directly. I don't want to use dwarf line mapping table as a bridge. I think the binary is generated by clang and llvm. I think there definitely

There should be a line-table entry for the end of the function, which appears to be missing from the dump you provided. llvm-dwarfdump should report this address with 'end_sequence' in the Flags. Are you using a different dumper? I am not sure but my guess would be that inline data is not represented in the line table. The line table's primary purpose is to inform the debugger

I'm not familiar with the target instruction set, but if "MOV PC, R0" is not a return instruction, I'm guessing that the sequence starting at A39C is a dispatch through a jump table. The jump table would be considered part of the instruction stream and included in the scope of the line table. This is not a case where you would see end_sequence; my mistake. The line table does

Hi paulr Thanks for your reply. Though DWARF info give me the code address ranges, there might be inline data. If so, how to handle this case? As for the dwarf line table. Sometimes, the source line might be zero. Do you know why? If all instructions should be describe in the line table, I think analyzing Dwarf line table is enough to get all the instructions addresses. Do you agree? I would

Hi Actually, No particular reason. I just think this might be a solution, then I use think kind of method. Querying the symbol table would be a good choice, but I prefer to use LLVM and dwarf information. I am sorry that I am not familiar with debug_info. But thanks to your suggestions. I would like to try to solve it with debug_info. It seems work according to your comments By the way, I am

Hi Alex Thanks for your email. But it seems not work. I removed the -fsanitize=address flag. The global buffer overflow message doesn't show. However, no *.sancov file is created after I run perlbench. Thus, I could not get the BB coverage. Do you have any ideas? Many Thanks Regards Muhui Alexander Potapenko <glider at google.com> 于2018年9月5日周三 下午7:14写道： > Hi Muhui, > > If

Hi Now I am using clang and llvm to do cross compiling. My target architecture is arm and the host is x86-64. I am trying to compile coreutils and SPEC2006(Anyone who ever has the same experience, please tell me. Really need your help) At the same time, I hope to generate the LLVM IR, which I can write PASS to extract some information. I would also need the dwarf debug information. I briefly

Hi I installed the llvm and clang according to the official documentation. Then I add the build/bin path to the environment and source the bashrc. My OS is ubuntu 14.04. However, when I typed clang --version. I have the following exception The program 'clang' can be found in the following packages: * clang-3.3 * clang-3.4 * clang-3.5 Try: sudo apt-get install <selected

Hi Krzysztof Thank you very much for your quick and clear reply. I know that MIR may not match hardware instructions directly. However, I think the semantics should be similar. For example, the first instruction is a store-multiple instruction in ARM. I think the first four MIR I shown should have the similar semantics with the first three hardware instructions. I still cannot see the

> On May 22, 2018, at 8:06 AM, Muhui Jiang via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi > > I am using llvm-dwarfdump to dump the line table with -debug-line option. I compiled my program with -gdwarf-3. > > I first get the line number and source number for every instruction of the LLVM IR with metadata. Then I try to find the corresponding binary address

Hi Muhui, I tried to grep the "DW_TAG_subprogram" from the debug_info . However, I noticed that the number I found is still less than the whole functions I found with LLVM IR. Do you have any experiences? Many Thanks The only explanation that comes to mind, is that the functions are not in the final binary object file. However, previously you said you believed they were present. If

Hi Krzysztof I see and I agree with your explanation However, you know some start of art binary analysis tools like angr will accept LLVM's such kind of design. You know there are some non-return functions. Does LLVM consider this? Do you have any ideas if I want to create a block that cannot contain function calls with LLVM IR. Regards Muhui 2018-05-29 21:20 GMT+08:00 Krzysztof Parzyszek