From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 53546 invoked by alias); 30 Oct 2019 23:59:49 -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 53097 invoked by uid 89); 30 Oct 2019 23:59:49 -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=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=HX-Languages-Length:1837 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE 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: mail-pf1-f195.google.com Received: from mail-pf1-f195.google.com (HELO mail-pf1-f195.google.com) (209.85.210.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 30 Oct 2019 23:59:48 +0000 Received: by mail-pf1-f195.google.com with SMTP id r4so2854424pfl.7 for ; Wed, 30 Oct 2019 16:59:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osandov-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=DfvuUDsXmZVl43JCeTUZOz9ySeARtanO1tq2fVzefeE=; b=QMwd91B0L1kVn4C0oNUVwB6X3o27zpLf6Ijcqt4+jAvA8D7UqjHkztgBVbFttN4EpR eKX/gB+i89gwVAKoqAxDaLkQatIhlkMR2J/LHpl5t6QSezlzn+2hkaCtFkSi5xy4MtJ2 QAS6MxgokjxW1L8oJo9mI6dHTuokMPlk/Gc60uufS6o0g2RkxyqWd/YW0W8jChr+uZEL 9OtmE/e98w0eLpUrpaKLSBjgz1dAahj/AdTAeQm657NhUSmMWsDb9moFG7RhDdPK9ypv M6oEn+cBFLZY+PihVLUtUXLagKFgWIkYrhlncDCMfeZ5rOdNGBWEfDEc60aGBf1DQmSD T+zA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=DfvuUDsXmZVl43JCeTUZOz9ySeARtanO1tq2fVzefeE=; b=iLe7yXeOSB2J1zjXDzyr83Y7no8e71J9D/Te7eAhOLBiOwORmZlFhz0SBm2L5rL6c/ qN0BN/tx0OXNoXf1yPy9gtlohJrjF/XzcunDkDnpvBHBvWZziX0/1GBAXovW3Ytxi/C1 nyFC1pCkE5QrxFeX0my/H/CbUA0NCWKLBaW6XCyAP+iuRT4bXt2mUnPo9qESCWnP+Qax 5cHUzVJyHsQW1P2B/mFJQt8MPSBmq3WzXfEID2JrCc0MdpuU/qX5dXL9JcazRN7L5gYZ b9TWFGIstRhugxmbd4iycHvx2LdI8dYmeH3rzeo2fC8eaGFCUv2yBiuhhKNuV/C6FoCP lXPg== X-Gm-Message-State: APjAAAX2dQ0qlpmfqYyk1vaAAph7yMsnn+m3SXnIMLqE3Gyw08crd1xl ntYRAGj3czpnELP5oF8YmQMBEw== X-Google-Smtp-Source: APXvYqw9ganFDSvXdk0xCrRe8bAY1ifxDuvN804c7/5eA15b1OgZpN0duteuRRIf1rh1a3ChdNZM0A== X-Received: by 2002:a17:90a:3be4:: with SMTP id e91mr2702700pjc.56.1572479986367; Wed, 30 Oct 2019 16:59:46 -0700 (PDT) Received: from vader ([2620:10d:c090:180::3912]) by smtp.gmail.com with ESMTPSA id u10sm2976351pjy.28.2019.10.30.16.59.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 30 Oct 2019 16:59:45 -0700 (PDT) Date: Wed, 30 Oct 2019 23:59:00 -0000 From: Omar Sandoval To: Mark Wielaard Cc: elfutils-devel@sourceware.org Subject: Re: [PATCH 5/5] libdwfl: add interface for evaluating DWARF expressions in a frame Message-ID: <20191030235945.GK326591@vader> References: <340240576c11f97cd326f76b7decd9164c74e91e.1570438723.git.osandov@fb.com> <7bb91fd1006b5346013093bfaa6c6981035588e4.camel@klomp.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7bb91fd1006b5346013093bfaa6c6981035588e4.camel@klomp.org> User-Agent: Mutt/1.12.2 (2019-09-21) X-IsSubscribed: yes X-SW-Source: 2019-q4/txt/msg00089.txt.bz2 On Wed, Oct 30, 2019 at 02:23:06PM +0100, Mark Wielaard wrote: > Hi Omar, > > On Mon, 2019-10-07 at 02:05 -0700, Omar Sandoval wrote: > > libdwfl can evaluate DWARF expressions in order to unwind the stack, > > but this functionality isn't exposed to clients of the library. Now that > > the pieces are in place, add dwfl_frame_eval_expr to provide this feature. > > I think this is useful. But same issue as the previous patch that I am > not sure the error handling is correct for state->frame == NULL. The change I described for the previous patch should fix that. > Also this could really use some examples and maybe a small testcase. > > That would show how to handle DWARF expressions to are simple location > descriptions (which calculate a location where a value can be found) > versus implicit location descriptions (e.g. DW_OP_value) versus > composite location descriptions (e.g. DW_OP_piece). > > It might be that we don't care, because all we care about is whether or > not we can get a value, but it would validate the interface. > > Having some examples/testcases would also show how/where to get the > DWARF expressions to use with this new function. Sounds good, I'll put some examples/test cases together. FWIW, I'm using it in drgn to get register values like so: LIBDRGN_PUBLIC struct drgn_error * drgn_stack_frame_register(struct drgn_stack_frame frame, enum drgn_register_number regno, uint64_t *ret) { const Dwarf_Op op = { .atom = DW_OP_regx, .number = regno, }; Dwarf_Addr value; if (!dwfl_frame_eval_expr(frame.trace->frames[frame.i], &op, 1, &value)) return drgn_error_libdwfl(); *ret = value; return NULL; } Later, I plan to use this for location expressions for local variables that I get out of DWARF. Thanks, Omar