From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31571 invoked by alias); 10 May 2019 23:39:22 -0000 Mailing-List: contact elfutils-devel-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: elfutils-devel-owner@sourceware.org Received: (qmail 31537 invoked by uid 89); 10 May 2019 23:39:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.3 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.8 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=pushes X-Spam-Status: No, score=-6.8 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on sourceware.org X-Spam-Level: X-HELO: gnu.wildebeest.org Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (212.238.236.112) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 10 May 2019 23:39:20 +0000 Received: from librem.wildebeest.org (deer0x15.wildebeest.org [172.31.17.151]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id E190F30130E6; Sat, 11 May 2019 01:39:17 +0200 (CEST) Received: by librem.wildebeest.org (Postfix, from userid 1000) id 90FEBC17B8; Sat, 11 May 2019 01:39:17 +0200 (CEST) Date: Fri, 10 May 2019 23:39:00 -0000 From: Mark Wielaard To: Sasha Da Rocha Pinheiro Cc: "elfutils-devel@sourceware.org" Subject: Re: Dwarf_Op Message-ID: <20190510233917.GB15599@wildebeest.org> References: <20190427175707.GI25602@wildebeest.org> <20190501230213.GD39969@wildebeest.org> <20190503210929.GK39969@wildebeest.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Flag: NO X-IsSubscribed: yes X-SW-Source: 2019-q2/txt/msg00075.txt.bz2 On Wed, May 08, 2019 at 06:03:55PM +0000, Sasha Da Rocha Pinheiro wrote: > About the *ops returned from dwarf_frame_register(): > Is it correct to say that if we don't get a DW_OP_stack_value as the > last operation, the value on top of the stack will always be a > memory address? Meaning you must dereference it? Even though there > is no DW_OP_deref provided as last operation? If not, what else > could it be? There could be no operations at all, an empty location description, then there simply is no location/value. It could be a single register location description operation (DW_OP_reg[0..31] or DW_OP_regx) that says the value is in that particular register (note this is different from the DW_OP_bregx operations which pushes the contents of the register on the expression stack). Or it is one or more of the other operations which leave the location (an address) on the expression stack. If the last operation is DW_OP_stack_value then the value on the top of the expression stack is the value itself (and not a location where the value can be changed). Technically it can also be an DW_OP_implicit_value (again a value, not a location), and DW_OP_implicit_pointer (a "fake" pointer/location, but really a description of the value of that location), or a composite location description (DW_OP_[bit_]piece, multiple location descriptions that have to be combined to get the value). But these don't come from dwarf_frame_register at the moment. > Another issue: I am trying to decode the following *ops: > DW_OP_call_frame_cfa DW_OP_stack_value This was returned after I > requested register 31 (SP in aarch64) at address 0x40091c. As you > can see below, I pasted the CIE and FDE relative to this address > using eu-readelf and dwarfdump. Is it that, in this case, > DW_OP_call_frame_cfa means "get the CFA value at 0x00400918"? Why > isn't SP rule undefined or same_value, instead of those two > operations? Yes, that looks circular, but it is meant to be "efficient". Often registers can be found at an offset of the current CFA (or in this case, it is the CFA value). You get the CFA for a frame with dwarf_frame_cfa (), which works similar to dwarf_frame_register (), the CFA itself doesn't have/is a register number however. Hope that helps, Mark