<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Thanks for investigating. Could you file a report on <a href="http://bugs.llvm.org">bugs.llvm.org</a> so that we can track this issue?<br><br><div id="AppleMailSignature" dir="ltr">vedant (sent from my iPhone)</div><div dir="ltr"><br>On Sep 11, 2019, at 6:06 AM, Sourabh Singh Tomar <<a href="mailto:sourav0311@gmail.com">sourav0311@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><div dir="ltr">Hi Djordje,<div><br></div><div>> The 'func()' gets inlined, so according to the DWARF standard the call-site debug info should not be created for calls to inlined functions <br></div><div><br></div><div>Thanks for sharing this, Now the real problem is getting values of this optimized parameter "ptr" since func is inlined, variable ptr has location in debug_loc section {assuming DWARF-4}.</div><div>but for CLANG compiled binaries, gdb is reporting optimized out.</div><div><br></div><div>Reading symbols from test1_clang_O2...<br>(gdb) b func(int*)<br>Breakpoint 1 at 0x2010f4: func(int*). (2 locations)<br>(gdb) r<br>Starting program: /doc/test1_clang_O2<br><br>Breakpoint 1, func (ptr=<optimized out>) at test1.cpp:4<br>4 std::cout << *ptr;<br>(gdb) print *ptr<br>value has been optimized out<br><br></div><div>For GCC-9.2 compiled binaries, I'm able to print this optimized out the value of optimized out "ptr" variable. </div><div>Please note that GCC-9.2 is also emitting an extra DW_OP_GNU_implicit_poitner along with DW_OP_GNU_entry_value, DW_OP_stack_value. DW_OP_GNU_implicit_pointer is not emitted by CLANG.</div><div><br></div><div>>> The new work is also implemented on the MIR level. <br></div><div>Thanks for clarifying this.</div><div><br></div><div>Thanks!</div><div>Sourabh.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 11, 2019 at 5:16 PM Djordje Todorovic <<a href="mailto:djordje.todorovic@rt-rk.com">djordje.todorovic@rt-rk.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Sourabh,<br>
<br>
> #include <iostream><br>
> int func(int* ptr){<br>
> std::cout << *ptr;<br>
> return *ptr + 5;<br>
> }<br>
> int main(int argc, char** argv){<br>
> int a = 4;<br>
> int* ptr_a = &a;<br>
> int b = func(ptr_a);<br>
> return 0;<br>
> }<br>
<br>
The 'func()' gets inlined, so according to the DWARF standard the call-site debug info should not be created for calls to inlined functions.<br>
<br>
>@Djorde DW_TAG_call_site are supported using late MIR approach, are the new Call Site related development will be supported via MIR. or their will be a frontend level debug metadata support will be added.<br>
<br>
The new work is also implemented on the MIR level.<br>
<br>
Best,<br>
Djordje<br>
<br>
On 11.9.19. 13:07, Sourabh Singh Tomar wrote:<br>
> Hello Djordje, Vedant,<br>
> <br>
> Thanks a lot for sharing information. <br>
> <br>
> I have a doubt, please consider the following simple test case-<br>
> #include <iostream><br>
> int func(int* ptr){<br>
> std::cout << *ptr;<br>
> return *ptr + 5;<br>
> }<br>
> int main(int argc, char** argv){<br>
> int a = 4;<br>
> int* ptr_a = &a;<br>
> int b = func(ptr_a);<br>
> return 0;<br>
> } <br>
> commandline used --<br>
> bash$ clang++ -Xclang -femit-debug-entry-values -O2 -ggdb test.cpp<br>
> <br>
> For this case-- these Tags are not emitted<br>
> DW_TAG_call_site, DW_TAG_call_site_paramter ..<br>
> only DW_AT_GNU_all_call_sites attribute is present.<br>
> <br>
> + @Djorde DW_TAG_call_site are supported using late MIR approach, are the new Call Site related development will be supported via MIR. or their will be a frontend level debug metadata support will be added.<br>
> <br>
> Thanks!<br>
> Sourabh.<br>
> <br>
> <br>
> <br>
> On Wed, Sep 11, 2019 at 12:02 PM Djordje Todorovic <<a href="mailto:djordje.todorovic@rt-rk.com" target="_blank">djordje.todorovic@rt-rk.com</a> <mailto:<a href="mailto:djordje.todorovic@rt-rk.com" target="_blank">djordje.todorovic@rt-rk.com</a>>> wrote:<br>
> <br>
> Great to see this! :)<br>
> <br>
> Best,<br>
> Djordje<br>
> <br>
> On 10.9.19. 21:16, Vedant Kumar wrote:<br>
> ><br>
> ><br>
> >> On Sep 10, 2019, at 6:15 AM, Djordje Todorovic via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>>> wrote:<br>
> >><br>
> >> Hi Sourabh,<br>
> >><br>
> >> Support for call-site related DWARF 5 tag/attributes is implemented very late, in the LLVM middle-end.<br>
> >> Please note that there is also the IR-level flag (DIFlagAllCallsDescribed) that lowers to<br>
> >> the DW_AT_call_all_calls.<br>
> >><br>
> >> There is also support for call-site-parameter (DW_TAG_call_site_parameter) and the debug entry values<br>
> >> (DW_OP_entry_value) related DWARF 5 symbols, but it is restricted by the CC1 option ‘-femit-debug-entry-values’,<br>
> >> since the LLDB is still missing support for that.<br>
> ><br>
> > Not for too long ;)<br>
> ><br>
> > See <a href="https://reviews.llvm.org/D67410" rel="noreferrer" target="_blank">https://reviews.llvm.org/D67410</a> & <a href="https://reviews.llvm.org/D67376" rel="noreferrer" target="_blank">https://reviews.llvm.org/D67376</a><br>
> ><br>
> > best,<br>
> > vedant<br>
> ><br>
> >><br>
> >> Best regards,<br>
> >> Djordje<br>
> >><br>
> >> On 10.9.19. 13:58, Sourabh Singh Tomar via llvm-dev wrote:<br>
> >>> Hello All,<br>
> >>><br>
> >>> I was working on some dwarf-5 features and debugging optimized code support in clang and llvm. <br>
> >>><br>
> >>> Noticed that, DW_TAG_call_site is supported in llvm middle-end. but clang is not emitting these. <br>
> >>><br>
> >>> I was hoping, if someone could provide current status of these features and current status of dwarf-5 features in clang and llvm. <br>
> >>> That will be immensely helpful.<br>
> >>><br>
> >>> Thanks!<br>
> >>> Sourabh.<br>
> >>><br>
> >>> _______________________________________________<br>
> >>> LLVM Developers mailing list<br>
> >>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>><br>
> >>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
> >>><br>
> >> _______________________________________________<br>
> >> LLVM Developers mailing list<br>
> >> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>><br>
> >> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
> ><br>
> <br>
</blockquote></div>
</div></blockquote></body></html>