Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Yao Qi <qiyaoltc@gmail.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: Yao Qi <qiyaoltc@gmail.com>,
	 Andreas Schwab <schwab@linux-m68k.org>,
	 gdb-patches@sourceware.org
Subject: Re: [PATCH] Fix wrong assertions
Date: Fri, 29 May 2015 13:43:00 -0000	[thread overview]
Message-ID: <86382fpki0.fsf@gmail.com> (raw)
In-Reply-To: <20150529113101.GA15460@host1.jankratochvil.net> (Jan	Kratochvil's message of "Fri, 29 May 2015 13:31:01 +0200")

Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Hi, Jan,
thanks for your explanations... they are very helpful.

>> Further, what is "partially ambiguous result" in the comments below?
>
> The terminology seems bogus there.
>
> "partially ambiguous" was meant the chain:
> 	main -> a -> <???> -> d
> An intersection of all possible chains.
>

Sounds like "partially ambiguous" is equivalent to "ambiguous".

>
>> /* Determined tail calls for constructing virtual tail call frames.  */
>> 
>> struct call_site_chain
>>   {
>>     /* Initially CALLERS == CALLEES == LENGTH.  For partially ambiguous result
>>        CALLERS + CALLEES < LENGTH.  */
>>     int callers, callees, length;
>> 
>>     /* Variably sized array with LENGTH elements.  Later [0..CALLERS-1] contain
>>        top (GDB "prev") sites and [LENGTH-CALLEES..LENGTH-1] contain bottom
>>        (GDB "next") sites.  One is interested primarily in the PC field.  */
>>     struct call_site *call_site[1];
>>   };
>> 
>> I am confused by the usage of the variable-sized array call_site,
>> elements from 0 to CALLERS-1 are top sites, and elements from
>> LENGTH-CALLEES to LENGTH-1 are bottom sites, so I conclude that
>> CALLERS-1 < LENGTH-CALLEES, then CALLERS + CALLEES < LENGTH + 1,
>> then CALLERS + CALLEES =< LENGTH.  Is it right?
>
> Yes, that is right.  Initially there is some chain (let's say the longest one

If that is right, the assert below is too strict, isn't?

  /* See call_site_find_chain_1 why there is no way to reach the bottom callee
     PC again.  In such case there must be two different code paths to reach
     it, therefore some of the former determined intermediate PCs must differ
     and the unambiguous chain gets shortened.  */
  gdb_assert (result->callers + result->callees < result->length);

> but that doe snot matter).  Consequently its elements from the middle are
> being removed and there remains only some few unambiguous top and
> bottom ones.

If there is no call sites removed from the chain during the intersection,
CALLERS + CALLEES == LENGTH, right?  in function chain_candidate,
result->length is set by the length of a chain.  If this chain is the
shortest one, CALLERS + CALLEES == LENGTH otherwise,
CALLERS + CALLEES < LENGTH.  Is it right?  If so, we need to relax the
condition in the assert and update the comments.

>
> The original idea why the comparison should be sharp ("<") was that if there
> are multiple chains like (0xaddr show jmp instruction address):
> 	main(0x100) -> a(0x200) -> d(0x400)
> 	main(0x100) -> a(0x200) -> c(0x300) -> d(0x400)
> then - such situation cannot exist - if two jmp instructions in "a" have the
> same address they must also jump to the same address (*).
>
> (*) jump to a computed address would be never considered for the DWARF
>     tail-call records.
>
> So there could be:
> 	main(0x100) -> a(0x200) -> d(0x400)
> 	main(0x100) -> a(0x270) -> c(0x300) -> d(0x400)
> But then "a" frame itself is ambiguous and it must not be displayed.
>
> I did not realize that there can be self-tail-call:
> 	main(0x100) -> a(0x200) -> d(0x400)
> 	main(0x100) -> a(0x280) -> a(0x200) -> d(0x400)
> which intersects to:
> 	main(0x100) -> <???>? -> a(0x200) -> d(0x400)
> And so if the first chain was chosen the
> 	main(0x100) -> a(0x200) -> d(0x400)
> then the final intersection has callers+callees==length.

What are the definitions of CALLERS, CALLEES, top and bottom? given this example?

-- 
Yao (齐尧)


  reply	other threads:[~2015-05-29 13:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-09 18:57 Andreas Schwab
2015-05-13 14:01 ` Jan Kratochvil
2015-05-13 14:35   ` Andreas Schwab
2015-05-29  9:31   ` Yao Qi
2015-05-29 11:31     ` Jan Kratochvil
2015-05-29 13:43       ` Yao Qi [this message]
2015-05-29 14:10         ` Jan Kratochvil
2015-05-29 16:33           ` Yao Qi
2015-05-30  7:44             ` Jan Kratochvil
2015-06-01 11:35           ` Yao Qi
2015-06-01 12:05             ` [commit] " Jan Kratochvil
2015-05-19 20:47 ` [patch] testcase: tailcall assertion [Re: [PATCH] Fix wrong assertions] Jan Kratochvil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86382fpki0.fsf@gmail.com \
    --to=qiyaoltc@gmail.com \
    --cc=gdb-patches@sourceware.org \
    --cc=jan.kratochvil@redhat.com \
    --cc=schwab@linux-m68k.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox