From: Yao Qi <qiyaoltc@gmail.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: Andreas Schwab <schwab@linux-m68k.org>, gdb-patches@sourceware.org
Subject: Re: [PATCH] Fix wrong assertions
Date: Fri, 29 May 2015 09:31:00 -0000 [thread overview]
Message-ID: <86bnh3pw61.fsf@gmail.com> (raw)
In-Reply-To: <20150513140106.GB3023@host1.jankratochvil.net> (Jan Kratochvil's message of "Wed, 13 May 2015 16:01:06 +0200")
Jan Kratochvil <jan.kratochvil@redhat.com> writes:
> That '<' and not '<=' was there intentional. Personally I think it needs more
> investigation why that can happen. The idea was that if two solutions exist
> neither can be perfect so there have to be some ambiguous enties so there will
> be '<' and not '<=' (to fit the ambiguous entries between).
>
> But creating artifical reproducers is a bit difficult and you haven't provided
> a reproducer so I cannot say anything much specific.
>
> Personally I do not mind, it is up to the maintainers whether the goal is just
> to remove the assertion or verify there aren't some other bugs causing it.
I can reproduce this internal error via Jan's test case, and spend some
time investigating it, but still unable to fully understand the code.
Jan, since you wrote this piece of code, please help me to understand
it.
(gdb) set debug entry-values 1
(gdb) bt
tailcall: initial: 0x40052e(a)
tailcall: compare: 0x400527(a) 0x40052e(a)
tailcall: reduced: | 0x40052e(a)
gdb/git/gdb/dwarf2loc.c:834: internal-error: chain_candidate: Assertion `result->callers + result->callees < result->length' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) y
I don't know why we need do intersection in chain_candidate, as the
comments say:
/* Intersect RESULTP with CHAIN to keep RESULTP unambiguous, keep in RESULTP
only top callers and bottom callees which are present in both. GDBARCH is
used only for ENTRY_VALUES_DEBUG. RESULTP is NULL after return if there are
no remaining possibilities to provide unambiguous non-trivial result.
RESULTP should point to NULL on the first (initialization) call. Caller is
responsible for xfree of any RESULTP data. */
What do you mean by "ambiguous" here? Is it ambiguous if we can get
more than one call chain path from caller_pc to callee_pc? For example,
main tail calls a, a tail call b and c, b and c tail call d, when GDB
unwinds from d, there are two chains, main -> a -> b -> d, and main -> a
-> c -> d. Are they ambiguous by your definition?
Further, what is "partially ambiguous result" in the comments below?
/* 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?
I still have other questions, but I'd like to stop here, otherwise this
mail will be too long. Your answers to these questions may help to
answer the rest of my questions.
--
Yao (齐尧)
next prev parent reply other threads:[~2015-05-29 9:31 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 [this message]
2015-05-29 11:31 ` Jan Kratochvil
2015-05-29 13:43 ` Yao Qi
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=86bnh3pw61.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