From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 102360 invoked by alias); 29 May 2015 09:31:32 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 102338 invoked by uid 89); 29 May 2015 09:31:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pa0-f51.google.com Received: from mail-pa0-f51.google.com (HELO mail-pa0-f51.google.com) (209.85.220.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 29 May 2015 09:31:27 +0000 Received: by pacrp13 with SMTP id rp13so5184461pac.2 for ; Fri, 29 May 2015 02:31:25 -0700 (PDT) X-Received: by 10.68.192.98 with SMTP id hf2mr13264059pbc.142.1432891885064; Fri, 29 May 2015 02:31:25 -0700 (PDT) Received: from E107787-LIN (gcc1-power7.osuosl.org. [140.211.15.137]) by mx.google.com with ESMTPSA id mx5sm4946412pdb.75.2015.05.29.02.31.22 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 29 May 2015 02:31:24 -0700 (PDT) From: Yao Qi To: Jan Kratochvil Cc: Andreas Schwab , gdb-patches@sourceware.org Subject: Re: [PATCH] Fix wrong assertions References: <87vbg1eg08.fsf@igel.home> <20150513140106.GB3023@host1.jankratochvil.net> Date: Fri, 29 May 2015 09:31:00 -0000 In-Reply-To: <20150513140106.GB3023@host1.jankratochvil.net> (Jan Kratochvil's message of "Wed, 13 May 2015 16:01:06 +0200") Message-ID: <86bnh3pw61.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg00703.txt.bz2 Jan Kratochvil writes: > That '<' and not '<=3D' was there intentional. Personally I think it nee= ds more > investigation why that can happen. The idea was that if two solutions ex= ist > neither can be perfect so there have to be some ambiguous enties so there= will > be '<' and not '<=3D' (to fit the ambiguous entries between). > > But creating artifical reproducers is a bit difficult and you haven't pro= vided > 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 `re= sult->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 =3D=3D CALLEES =3D=3D LENGTH. For partially ambig= uous result CALLERS + CALLEES < LENGTH. */ int callers, callees, length; /* Variably sized array with LENGTH elements. Later [0..CALLERS-1] con= tain 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 =3D< 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. --=20 Yao (=E9=BD=90=E5=B0=A7)