From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30464 invoked by alias); 13 Dec 2013 13:01:14 -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 30432 invoked by uid 89); 13 Dec 2013 13:01:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mga09.intel.com Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 13 Dec 2013 13:00:20 +0000 Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 13 Dec 2013 04:56:32 -0800 X-ExtLoop1: 1 Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by orsmga002.jf.intel.com with ESMTP; 13 Dec 2013 04:59:57 -0800 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.135]) by IRSMSX102.ger.corp.intel.com ([169.254.2.114]) with mapi id 14.03.0123.003; Fri, 13 Dec 2013 12:59:51 +0000 From: "Metzger, Markus T" To: Pedro Alves CC: Jan Kratochvil , "gdb-patches@sourceware.org" Subject: RE: [patch v8 05/24] frame: artificial frame id's Date: Fri, 13 Dec 2013 13:01:00 -0000 Message-ID: References: <1386839747-8860-1-git-send-email-markus.t.metzger@intel.com> <1386839747-8860-6-git-send-email-markus.t.metzger@intel.com> <52AA10DD.2020506@redhat.com> <20131212195531.GA6092@host2.jankratochvil.net> <52AAF8EA.4020608@redhat.com> In-Reply-To: <52AAF8EA.4020608@redhat.com> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2013-12/txt/msg00529.txt.bz2 > -----Original Message----- > From: gdb-patches-owner@sourceware.org [mailto:gdb-patches- > owner@sourceware.org] On Behalf Of Pedro Alves > Take a look at this patch: >=20 > https://sourceware.org/ml/gdb-patches/2013-04/msg00541.html >=20 > It seems to me your frames are exactly like those, though > it sounds like you may have more than one frame with stack > unavailable, and with the same code address, but that should > be identified as different frames (please confirm). In that > case, it seems like you could use the artificial depth to > distinguish them. I have several frames, none of them has an available stack. It's either my frames or some other frames. They are never mixed. I may also have frames with the same code address and they would need to be identified as different frames - confirmed. I'm assigning a unique identifier to special so I can distinguish frames that have the same code address. That identifier is preserved during stepping. Afaik, the artificial depth is used for artificial frames beneath a real frame. It's used for inline and tailcall frames. The artificial_depth field is a simple counter. This does not quite match what I need. Since all frames in my stack are artificial, I wouldn't have a real frame on top from which to start counting. So I would count from the sentinel frame and the artificial_depth would be equal to the frame level. I could imagine that this would cause problems during stepping when trying to detect stepping into subroutines by comparing frame_id's. I could set stack_p to -1 instead of 0, though. Looks like this already addresses some of the problems you listed. Do you have tests that demonstrate the issues you mentioned? The tests in the repo behave identical with or without my changes. regards, markus. Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052