search for: jiangmuhui

...call global initializers prior to the start of the 'main()' function, but can occur in other situations. I hope this addresses at least some of your questions. I am happy to continue this discussion if some questions remain or if you have new questions. --paulr From: Muhui Jiang [mailto:jiangmuhui at gmail.com] Sent: Tuesday, June 26, 2018 9:38 AM To: Robinson, Paul Cc: Yajin; llvm-dev Subject: Re: [llvm-dev] Instruction boundaries Hi Paulr I am using the llvm-dwarfdump. This is not the end of the function, thus there is no 'end_sequence' reported. Here I just want to give you an e...

...e table. The line table's primary purpose is to inform the debugger about good breakpoint locations, and clearly you do not want to set breakpoints in data. Inline data is probably contained within the code ranges described in the DW_TAG_subprogram, however. --paulr From: Muhui Jiang [mailto:jiangmuhui at gmail.com] Sent: Tuesday, June 26, 2018 1:44 AM To: Robinson, Paul Cc: Yajin; llvm-dev Subject: Re: [llvm-dev] Instruction boundaries Hi Paulr According to my observation. Not all the instructions are listed in the line table. For example. We have address 0xa3a0 and 0xa3a4 as the instruction...

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 My goal is that given a binary and the corresponding input. I want to know what IR level basic blocks are covered. I need the detail information, which is the set of all the covered BBs rather than just a number. I want to know whether there are some tools that can support this requirements. If not, I think maybe instrumentation can helps. However, I do not know too much about this. Any

...ards Muhui Alexander Potapenko <glider at google.com> 于2018年9月5日周三 下午7:14写道： > Hi Muhui, > > If you want just the coverage information you can remove the > -fsanitize=address flag from the command line. > > HTH, > Alex > On Wed, Sep 5, 2018 at 1:06 PM Muhui Jiang <jiangmuhui at gmail.com> wrote: > > > > Hi > > > > If so, is it able to disable this check. All I need is just to get the > BB coverage information > > > > Regards > > Muhui > > > > Alexander Potapenko <glider at google.com>于2018年9月5日 周三下午6:57写...

...reduce it. CPU SPEC is the standard benchmark and I am not very familiar to the source code. The target binary is also rather large. Sorry for that. Regards Muhui David Blaikie <dblaikie at gmail.com> 于2018年11月4日周日 上午4:02写道： > > > On Sat, Nov 3, 2018 at 12:37 PM Muhui Jiang <jiangmuhui at gmail.com> wrote: > >> Hi Dave >> >> I am not going to access any hardware. >> > > Sorry, I meant the hardware you're using to compile LLVM - you mentioned > it took you a long time to rebuild it so it would be hard for you to > write/experiment on t...

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 Peter I guess this is the document written by you https://fosdem.org/2018/schedule/event/crosscompile/attachments/slides/2107/export/events/attachments/crosscompile/slides/2107/How_to_cross_compile_with_LLVM_based_tools.pdf I follow it to try to use the clang to do cross compilation. Actually, my target binaries is SPECCPU2006 and autotools based binaries. However, I failed on the first

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

...loc_1A54C Here you can see it obviously should not be a basic block because you called two functions! So the control flow graph LLVM generated is also not the real control flow graph, right? Do anyone know why or give me some suggestions? Regards Muhui 2018-05-29 20:35 GMT+08:00 Muhui Jiang <jiangmuhui at gmail.com>: > Hi > > I am using the LLVM function pass to help me to do code analysis. I use > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180529/bd6a4873/attachment.html>

Hi I am using the LLVM function pass to help me to do code analysis. I use -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180529/a617b2c6/attachment.html>

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

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 If so, is it able to disable this check. All I need is just to get the BB coverage information Regards Muhui Alexander Potapenko <glider at google.com>于2018年9月5日 周三下午6:57写道： > This is a known problem in SPECCPU2006, see > https://github.com/google/sanitizers/wiki/AddressSanitizerFoundBugs > On Wed, Sep 5, 2018 at 7:36 AM Muhui Jiang via llvm-dev > <llvm-dev at

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>

Hi Dave I am not going to access any hardware. I am using clang to analysis the ARM binaries. The binary is 483.xalancbmk in CPU SPEC2006. When I use the optimization O0, no crash will occur. The crash occurs when I set optimization level as O1,O2,O3 and Os. If I have to recompile and rerun the tests. What version of llvm is suggested. It would be better if anyone could provide the patch on this

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