search for: muhui

...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 suggestions or ideas are welcome. Thank you so much Regards Muhui -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180903/d36de489/attachment.html>

...presented in the line 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...

...things like code to 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 j...

...or 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 also cc my supervisor for the discussion. Regards Muhui <paul.robinson at sony.com>于2018年6月26日 周二上午2:38写道： > The main DWARF info should provide the code address ranges for each > function, as well as the starting source location. You could then use the > line table to map code ranges to individual source lines. That could give > yo...

...n is not complete. Sometimes the line number could even be zero. Besides, one line and column number could map to more than one binary address. Thus, I may need the mapping from IR to binary to give me a control flow graph on binary level. Do you have any comments or solutions? Many Thanks Regards Muhui 2018-06-13 23:05 GMT+08:00 <paul.robinson at sony.com>: > We preserve the source line/column for two reasons. First, so that any > compiler diagnostic messages can point to a source location that caused the > diagnostic; second, because debugging information in the final binary...

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 instruction might got > emitted into multiple assembly instruction, for example > > Zh...

...dress 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 is some information about the mapping relationship between LLVM IR and the target binary address. Do anyone has suggestions? Many Thanks Regards Muhui -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180612/691588c8/attachment.html>

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 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...

...y to solve it with debug_info. It seems work according to your comments By the way, I am still curious about the reason, why dwarf line mapping table would lost so many function's start addresses' information. It would be great if you have any comments on this problem. Many Thanks Regards Muhui 2018-06-01 23:00 GMT+08:00 David Blaikie <dblaikie at gmail.com>: > Any particular reason you're using debug info to achieve this (& if you > are, why you're using the line table?)? You could query the > object/executable file's symbol table to find all the function...

...n for very big program like gcc. The number of thumb mode instruction is less than 100. I get the ground truth from the mapping table. Maybe the flag I use is not right? I think there should be many thumb mode instructions. How do clang select thumb or arm mode when compiling? Many Thanks Regards Muhui -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181108/5c73e4c2/attachment-0001.html>

...ebugging information on the mode of ARM. For example, llvm-dwarfdump could dump some instructions information for debugging. Is it able to know the mode for each instruction? Or we may write some llvm pass to help us to know the instruction mode? Any suggestions are welcomed. Many Thanks Regards Muhui -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180628/7f06be4d/attachment.html>

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 f...

...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 relationships between them. Also, what does gpr mean.. Do I lost some information? Thank you so much if you can explain it in a little bit detail. Regards Muhui 2018-06-15 12:33 GMT-04:00 Krzysztof Parzyszek via llvm-dev < llvm-dev at lists.llvm.org>: > That's a store-multiple that saves a few registers at the entry to the > function. It's a part of the frame setup and it's generated during > prolog/epilog insertion. > &gt...

...not bijective. I am using O1 optimization option. I know that some of the information might be lost legitimately because of optimization. But I don't think dwarf will miss so many functions' start addresses. Am I right? Any useful comments and suggestions are welcomed. Many Thanks Regards Muhui -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180601/1399953e/attachment.html>

...g information to extract the source lines belonging to every functions. Then use the dwarf mapping table to transfer the source level information to binary address. Are there any better methods? Besides, is the address listed inside dwarf line mapping table must be code rather than data? Regards Muhui -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180625/9ea49a2a/attachment.html>

...t should be the same as the one I generated by using "llvm-dis *.preopt.bc -o *.preopt.ll" to translate the bitcode to IR. Actually, I would like to obtain the control flow information from the LLVM IR. Will different stages of the bitcode influence the generated CFG? Many Thanks Regards Muhui 2018-05-15 21:19 GMT+08:00 Teresa Johnson <tejohnson at google.com>: > 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...

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 lists.llvm.org> wro...

...VM 3.4. I compiled my code with the latest LLVM, whose version is 7.0. Anyone know whether the bitcode could be used by KLEE. Or do I have to compile with the old version of LLVM again. Furthermore, if you have any other concolic execution framework, please recommend it to me. Many Thanks Regards Muhui -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180714/5aeac547/attachment.html>

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> wrote: > >> Hi >> >> I am using LLVM to help me do some code analysis. I wrote a LLVM Functi...

...orresponding binary address from the dwarf debug info. However, I noticed that the dwarf table might not always return me the answer and some of the source line and column number is not found inside dwarf table. Do anyone have the same experiences? How do you handle this case. Many Thanks Regards Muhui -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180522/de487a6e/attachment.html>