From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20932 invoked by alias); 1 May 2019 17:08: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 20864 invoked by uid 89); 1 May 2019 17:08: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=-5.7 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_1,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=HContent-type:plain, HContent-type:iso-8859-1, HX-Languages-Length:2875, delegates X-Spam-Status: No, score=-5.7 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_1,SPF_HELO_PASS,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: wmauth4.doit.wisc.edu Received: from wmauth4.doit.wisc.edu (HELO wmauth4.doit.wisc.edu) (144.92.197.145) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 01 May 2019 17:08:19 +0000 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-co1nam04lp2053.outbound.protection.outlook.com [104.47.45.53]) by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.1.2.20170621 64bit (built Jun 21 2017)) with ESMTPS id <0PQU08IG64XS3560@smtpauth4.wiscmail.wisc.edu> for elfutils-devel@sourceware.org; Wed, 01 May 2019 12:08:17 -0500 (CDT) X-Spam-Report: AuthenticatedSender=yes, SenderIP=[104.47.45.53] X-Wisc-Env-From-B64: ZGFyb2NoYXBpbmhlQHdpc2MuZWR1 X-Spam-PmxInfo: Server=avs-4, Version=6.4.6.2792898, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2019.5.1.165716, AntiVirus-Engine: 5.60.0, AntiVirus-Data: 2019.4.29.5600002, SenderIP=[104.47.45.53] DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wisc.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Xgzk/HSFjMq4EzazeppbxAuBI2/RJtENUSoimQJNEwk=; b=Z5cmopxKGYWW/ZmvJJjbiKMqIRgJp1pxBFSpTepuRZUco/5N929weYOrmafhfjmuO8Mx8ZAeZn88cTlbGfiW4jpSJQoQItLjw6aRqJGOq/gfXsKtRamEv74eftRtLT9ZLnhzIqHbMVUeoWTBTG6CB/n+LCh+/bPiGPS102r12u8= Received: from DM5PR06MB3369.namprd06.prod.outlook.com (10.174.243.142) by DM5PR06MB3244.namprd06.prod.outlook.com (10.174.241.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.11; Wed, 1 May 2019 17:08:15 +0000 Received: from DM5PR06MB3369.namprd06.prod.outlook.com ([fe80::9d41:33c5:e37e:d862]) by DM5PR06MB3369.namprd06.prod.outlook.com ([fe80::9d41:33c5:e37e:d862%6]) with mapi id 15.20.1835.018; Wed, 1 May 2019 17:08:15 +0000 From: Sasha Da Rocha Pinheiro To: Mark Wielaard Cc: "elfutils-devel@sourceware.org" Subject: Re: Dwarf_Op Thread-topic: Dwarf_Op Thread-index: AQHU+8H12kpQfpdJAUigjjjwoCl6Z6ZOGluAgACK+fqAAahpgIAGNfzY Date: Wed, 01 May 2019 17:08:00 -0000 Message-id: References: , <20190427175707.GI25602@wildebeest.org> In-reply-to: <20190427175707.GI25602@wildebeest.org> Accept-Language: en-US, pt-BR Content-language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Originating-IP: [128.105.14.107] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 52862e02-8c98-4ec0-b81f-08d6ce5799dd x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0;PCL:0;RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020);SRVR:DM5PR06MB3244; x-ms-traffictypediagnostic: DM5PR06MB3244: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 00246AB517 x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(396003)(136003)(366004)(376002)(346002)(39860400002)(189003)(199004)(8676002)(76116006)(6246003)(2906002)(66946007)(73956011)(4326008)(6436002)(6116002)(3846002)(786003)(316002)(55016002)(53936002)(75432002)(86362001)(476003)(9686003)(7696005)(446003)(11346002)(99286004)(486006)(66556008)(33656002)(25786009)(81166006)(66446008)(64756008)(66476007)(81156014)(8936002)(52536014)(478600001)(53546011)(6506007)(76176011)(102836004)(256004)(6346003)(186003)(26005)(6916009)(229853002)(71200400001)(71190400001)(68736007)(7116003)(88552002)(5660300002)(14454004)(66066001)(305945005)(7736002)(74316002);DIR:OUT;SFP:1101;SCL:1;SRVR:DM5PR06MB3244;H:DM5PR06MB3369.namprd06.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;MX:1;A:1; Received-SPF: None (protection.outlook.com: wisc.edu does not designate permitted sender hosts) Authentication-results: spf=none (sender IP is ) smtp.mailfrom=darochapinhe@wisc.edu; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: ZzP6ToxdmFvkpUMJgkptJBNkTvRZsVC0UWA+4wcg37Y34kDC0o96uhjbPXxbFt6vtTOFefp1Y91m/sjxt9hHcS10YWXepKrPX3XnOUodcMOJs5YHOAKbyERfubEdJaFD9zoHEortcpv1bh2OIsnCLQbn3w58sCQO+GfvLTSnEwRT9gTs9NJq5NNn+ifNMimDJvRnHEBKc3oLKacMXL15AxzZfWifezwM+/zX03yu19dB7Mw7SA7pDSlEo6JrCPldlS8jznJYCpekiG/PCmhxRgNrIevY5l1vtBQvqBFJkx1wQYrL81SOj6WZuXOu4ydO5wgpY3fAkB4EwpWQD2s/YLVyFCS1HEGsk5igTgQ41I5bJDaOMWwsvx4KFovAOkPLNp1XtTqldhM7sKUsnx3S2q5PUyiKsHNukTCzNmEXm0U= Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: quoted-printable MIME-version: 1.0 X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-Network-Message-Id: 52862e02-8c98-4ec0-b81f-08d6ce5799dd X-MS-Exchange-CrossTenant-originalarrivaltime: 01 May 2019 17:08:15.7634 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ca68321-0eda-4908-88b2-424a8cb4b0f9 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR06MB3244 X-SW-Source: 2019-q2/txt/msg00054.txt.bz2 Hi Mark, yes, I did use dwarf_frame_register(), I believe I mentioned that :). In the case I brought up you're saying it was an elfutils' libdw decision t= o provide negative number as DW_OP_plus_uconst (unsigned constant)? So ther= e would be no harm to cast it to a signed int?? Do you know if the rules to find the registers will always have only anothe= r one register associated to it? Because libdwarf function dwarf_get_fde_in= fo_for_reg3() returns a register_num, which is described as: "Argument register_num should point to a location which will hold the regis= ter number associated with the register rule." elfutils only gives us a location description in an array of Dwarf_Op. Does= it provide methods to "execute" it so we can get the result of the express= ions? Or it delegates it to the consumer? Regards Sasha From: Mark Wielaard Sent: Saturday, April 27, 2019 12:57 PM To: Sasha Da Rocha Pinheiro Cc: elfutils-devel@sourceware.org Subject: Re: Dwarf_Op =A0 On Fri, Apr 26, 2019 at 04:48:49PM +0000, Sasha Da Rocha Pinheiro wrote: > The output from dwarfdump: > > <=A0=A0=A0 5><0x00400918:0x00400974>
>=A0=A0=A0=A0=A0=A0=A0 >=A0=A0=A0=A0=A0=A0=A0=A0 0x00400918: >=A0=A0=A0=A0=A0=A0=A0=A0 0x0040091c: >=A0=A0=A0=A0=A0=A0=A0=A0 0x00400920: >=A0=A0=A0=A0=A0=A0=A0=A0 0x00400970: > > I'm getting the rules for r30 at PC 0x0040091c. > The value you see -24 from cfa is passed delivered by libdw as: > > (gdb) p/x locations[i] > $19 =3D {atom =3D 0x23, number =3D 0xffffffffffffffe8, number2 =3D 0x0, o= ffset =3D 0x0} > > The atom here is DW_OP_plus_uconst. > Previously I have said it was 0xffffffe8, because the printf with specifi= er %x printed that way. But gdb seems to print its full 8 bytes. > I used dwarf_frame_register. > > Even though, the member number is of unsigned int type with signed encode= d values. Am I correct? Yes, a Dwarf_Op struct holds two number elements which are (unsigned 64bit) Dwarf_Words: typedef struct { =A0 uint8_t atom;=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /* Operat= ion */ =A0 Dwarf_Word number;=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /* Operand */ =A0 Dwarf_Word number2;=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /* Possible second op= erand */ =A0 Dwarf_Word offset;=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /* Offset in locati= on expression */ } Dwarf_Op; I assume you are using dwarf_frame_register () to turn the CFI for a particular register into a location expression (array of Dwarf_Ops). Which in this case would indeed produce DW_OP_call_frame_cfa, DW_OP_plus_uconst (with the constant -24 in number). Unfortunately there is no better/precise way to turn the CFI register rule into a Dwarf Expression Location. But note that if you use the Dwarf_Ops to calculate an Dwarf_Addr, then the 64bit unsigned arithmetic will work out (because the plus of the big unsigned constant will wrap around and turn into a small minus constant). Cheers, Mark