This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 1/2] Report call site for inlined functions
- From: Pedro Alves <palves at redhat dot com>
- To: Keith Seitz <keiths at redhat dot com>, gdb-patches at sourceware dot org
- Date: Fri, 27 Oct 2017 13:49:45 +0100
- Subject: Re: [PATCH 1/2] Report call site for inlined functions
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=palves at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 756EB4A6EB
- References: <1499740601-15957-1-git-send-email-keiths@redhat.com> <fca4dbcf-7772-f5d1-7b7a-24c2d9afd47a@redhat.com> <d047af4b-82cd-db80-0f0c-efce4a2831a2@redhat.com>
On 10/20/2017 07:46 PM, Keith Seitz wrote:
> [My reply seems not to have made it to sourceware, so I'm resending.]
>
> On 07/18/2017 12:05 PM, Pedro Alves wrote:
>> On 07/11/2017 03:36 AM, Keith Seitz wrote:
>>>
>>> Here you can see the new call-site-func, call-site-file, call-site-fullname,
>>> and call-site-line.
>>
>> The non-inlined call site seems sufficient info to me, at least for
>> the CLI. I'm not sure whether "call-site" is sufficiently clear that
>> it's referring to that vs the immediate potential inlined-too
>> caller though. I think at least the docs need such a clarification.
>
> There seems to be consensus on the (lack of) utility of this call-site info, so in the next revision (to follow), I've chosen to remove it all. I think that pretty much resolves (by deletion!) most of your concerns/comments. I've also removed the inlined_symbol proposal since that is also no longer necessary.
I think my observations in
<https://sourceware.org/ml/gdb-patches/2017-03/msg00382.html>
still make sense, and I don't know about consensus, but OK, let's
move on. I'll take a look at the new version.
>
>>> diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c
>>> index 0fdcd42..3b3193b 100644
>>> --- a/gdb/dwarf2read.c
>>> +++ b/gdb/dwarf2read.c
>>> @@ -11540,13 +11571,28 @@ read_func_scope (struct die_info *die, struct dwarf2_cu *cu)
>>> {
>>> templ_func = allocate_template_symbol (objfile);
>>> templ_func->base.is_cplus_template_function = 1;
>>> + symbol_storage = (struct symbol *) templ_func;
>>> break;
>>> }
>>> }
>>>
>>> + /* If we have an inlined symbol, we must also allocate a different
>>> + symbol. */
>>
>> How does this work when you have an (inlined) template function?
>> Like e.g.,:
>>
>> template<typename T>
>> static T inline_func (T val)
>> {
>> return val * 2;
>> }
>>
>> int
>> not_inline_func (int val)
>> {
>> return inline_func (val * 2);
>> }
>>
>
> I realize this was asked in relation to the proposed (and now deleted) inline_symbol, but to be clear, the above example works:
>
> (gdb) b inline_func<int>
> Breakpoint 1 at 0x4004c0: file inline-t.cc, line 9.
> (gdb) i b
> Num Type Disp Enb Address What
> 1 breakpoint keep y 0x00000000004004c0 in inline_func<int>
> at inline-t.cc:9
OK, it seems like a DIE can't be both DW_TAG_inlined_subroutine
and a template (kind of makes sense), so you couldn't ever end up
calling both allocate_template_symbol and allocate_inlined_symbol
for the same symbol (which is what I was worrying about, because
the code didn't consider/guard against that).
Thanks,
Pedro Alves