[llvm-dev] Function start address

[via llvm-dev]

[Re-sending with llvm-dev included this time]
Hi Muhui,
Are the functions emitted to the final binary?  If a function is not used, there might not be any object code for it in the final binary.  Naturally there would be no entry in the line table in this case.
If the function does exist in the binary, it is entirely possible (I think) to have no instruction specifically associated with the function definition's source line, even though other instructions are associated with other lines in the function.  I (or someone) would need to look at a specific example before being able to say one way or the other if that is what you are running into.

Have you considered building a static array of function addresses?  If you used weak references it would not interfere with optimizing away entire functions, which I mentioned above.  Or would that be too intrusive into your use case?  Apologies if this suggestion has come up before.
--paulr


From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Muhui Jiang via llvm-dev
Sent: Friday, June 01, 2018 6:36 AM
To: llvm-dev
Subject: [llvm-dev] Function start address

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180601/82782c52/attachment.html>