[llvm-dev] Function start address

[Muhui Jiang via llvm-dev]

Hi

One more thing I would like to confirm. It seems that the dwarf-info will
only contain the functions inside the .text section rather than the .plt
section. Am I right? You can check the attached file

Regards
Muhui

2018-06-04 13:18 GMT+08:00 Muhui Jiang <jiangmuhui at gmail.com>:

> Hi
>
> I would like to ask something more. From this experience, I think I didn't
> understand very well on the generation of LLVM IR.
>
> I am using autotools(configure, make) to compile the binaries. I use the
> LLVMgold.so and the -save-temps option to save the LLVM IR. If you have any
> other good suggestions on keeping the LLVM IR, especially on the
> compilation with autotools, please tell me. Many Thanks.
>
> Regards
> Muhui
>
> 2018-06-04 13:14 GMT+08:00 Muhui Jiang <jiangmuhui at gmail.com>:
>
>> Hi Paulr
>>
>> I think I've already know the reason. I use the -save-temps to help me to
>> save the LLVM IR during the compiling time.
>>
>> You know, there are four different kinds stages and every stage map to
>> one file for one binary. And they are
>>
>> *.preopt.bc
>> *.internalize.bc
>> *.opt.bc
>> *.precodegen.bc
>>
>> My LLVM Pass is running on *.preopt.bc so that I get 376 functions.
>> However, when I run the same pass on *.precodegen.bc. I get 266 functions,
>> which is the same number according to the symbol table. My mistake that I
>> didn't consider which bitcode file should I run. Thanks for your
>> suggestions.
>>
>> Regards
>> Muhui
>>
>>
>> 2018-06-04 3:08 GMT+08:00 <paul.robinson at sony.com>:
>>
>>> 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/20180604/cdbf9cc8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: new_cp
Type: application/octet-stream
Size: 344000 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180604/cdbf9cc8/attachment-0001.obj>