From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 49678 invoked by alias); 3 May 2019 21:09:38 -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 43754 invoked by uid 89); 3 May 2019 21:09:33 -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=-7.0 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=About, 1058, management, HContent-Transfer-Encoding:8bit X-Spam-Status: No, score=-7.0 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, 03 May 2019 21:09:31 +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 6F27530003AB; Fri, 3 May 2019 23:09:29 +0200 (CEST) Received: by librem.wildebeest.org (Postfix, from userid 1000) id 18252C2715; Fri, 3 May 2019 23:09:29 +0200 (CEST) Date: Fri, 03 May 2019 21:09:00 -0000 From: Mark Wielaard To: Sasha Da Rocha Pinheiro Cc: "elfutils-devel@sourceware.org" Subject: Re: Dwarf_Op Message-ID: <20190503210929.GK39969@wildebeest.org> References: <20190427175707.GI25602@wildebeest.org> <20190501230213.GD39969@wildebeest.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit 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/msg00063.txt.bz2 On Thu, May 02, 2019 at 07:29:33PM +0000, Sasha Da Rocha Pinheiro wrote: > So why not a DW_OP_constu or DW_OP_consts and then a DW_OP_plus? Probably because that is multiple operators and less efficiently encoded. But yes, it would be slightly more "correct" semantically. In this case however it is for computing (unsigned) addresses (CFA plus offset) in which case unsigned arithmetic is fine. > About the Dwarf_Op array we get from dwarf_frame_register(), (which > are a sequence of Dwarf expressions): are they suppose to be an > abstraction to all types of dwarf location descriptions? Including > Single (single and composite) and Location Lists? In theory yes, it is not a special kind of Dwarf Location Expression. It should be usable generially, although clearly it resolves in the context of the CFI (current pc and register values, memory, etc.). It turns the CFI for getting a register into a Dwarf Location Expression that you can use to resolve the value of that register. > Is there more documentation about dwfl? What does dwfl stand for? > (dwarf frame library?!) All documentation is in libdwfl.h for now. I am not sure dwfl officially stands for anything. But if ebl is the Elf Backend Library, then dwfl could be the libDW Frontend Library. > We already have access to the process memory space and registers, so > would expr_eval be suffice? Yes, if you are just looking for CFI/Unwinding then that should be enough. But expr_eval isn't a generic DWARF Expression evaluator so you cannot simply use it as is for generic DWARF Location Expressions coming from other parts of DWARF. > In case of finding the registers values at some PC, would it always > gives us a single expression (like an address or an offset from a > register)? Yes. > In the comment of dwarf_frame_register() in the file libdw.h, there > is: "Note the last operation is DW_OP_stack_value if there is no > mutable location but only a computable value." What is a mutable > location, I didn't find this concept in the Dwarf Debugging > Information Format v4. I believe "mutable locations" is what DWARF calls Location Descriptions, which point to a memory location or register where the value can be found (and so can be changed in that location). And what is called a "computable value" is what DWARF calls Implicit Location Descriptions, which provides a value itself (so there is no real location that can be changed). > Also there there is: > > 1057    For common simple expressions *OPS is OPS_MEM.  For arbitrary DWARF > 1058    expressions in the CFI, *OPS is an internal pointer that can be used as > 1059    long as the Dwarf_CFI used to create FRAME remains alive.  */ > > Why simple expression can only have 3 operations? (since Dwarf_Op ops_mem[3]) > And what's an arbitrary Dwarf expression? What's a non-arbitrary? It is "common simple expressions" vs "arbitrary expressions". The interface is made to make memory management easier (for the implementation of the function). But might be slightly confusing if you don't know that (you really shouldn't know about the internals). The idea is that most often the CFI expression can be turned into 1, 2 or 3 DWARF operators. The caller is asked to provide memory to store those. If the expression is bigger, then a pointer to internal storage is returned. In both cases you would just use *OPS for the *NOPS number of operations (in the first case *OPS points to your *MEM_OPS provided array, in the second case it points to some internal storage. Cheers, Mark