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 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 functions in an > object or executable, and the instruction/address they start at. Or, if you > are using debug info for some reason, you could look in the debug_info > rather than the line table, and find the DW_TAG_subprogram for each > function and look at its low_pc. > > On Fri, Jun 1, 2018 at 3:36 AM Muhui Jiang via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi >> >> I am using LLVM Pass combined with dwarf debug information to get all the >> function's start address. My steps are below: >> >> First, I write the function pass to get the start line of each function, >> which is finished. >> >> Then, based on the start line of every single function, I try to query >> the specific line from the dwarf's line binary table, which is generated >> with llvm-dwarfdump -debug-line. >> >> However, About one third of the whole functions' start line is not found >> in the mapping table. Thus, I can not get the start binary address. I know >> that the mapping between source locations and binary addresses is 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 >> _______________________________________________ >> LLVM Developers mailing list >> 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/20180602/4b421e9c/attachment.html>
Hi 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 Regards Muhui 2018-06-02 13:34 GMT+08:00 Muhui Jiang <jiangmuhui at gmail.com>:> 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 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 functions in an >> object or executable, and the instruction/address they start at. Or, if you >> are using debug info for some reason, you could look in the debug_info >> rather than the line table, and find the DW_TAG_subprogram for each >> function and look at its low_pc. >> >> On Fri, Jun 1, 2018 at 3:36 AM Muhui Jiang via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> Hi >>> >>> I am using LLVM Pass combined with dwarf debug information to get all >>> the function's start address. My steps are below: >>> >>> First, I write the function pass to get the start line of each function, >>> which is finished. >>> >>> Then, based on the start line of every single function, I try to query >>> the specific line from the dwarf's line binary table, which is generated >>> with llvm-dwarfdump -debug-line. >>> >>> However, About one third of the whole functions' start line is not found >>> in the mapping table. Thus, I can not get the start binary address. I know >>> that the mapping between source locations and binary addresses is 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 >>> _______________________________________________ >>> LLVM Developers mailing list >>> 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/20180603/95f15171/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 final binary object file. However, previously you said you believed they were present. If that is the case, please provide us with an example source file and compiler command line, to help diagnose the behavior. Thanks, --paulr -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180603/5c605cbe/attachment.html>