From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (wildebeest.demon.nl [212.238.236.112]) by sourceware.org (Postfix) with ESMTPS id BA79D383F872 for ; Sat, 6 Jun 2020 14:05:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org BA79D383F872 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mark@klomp.org Received: from tarox.wildebeest.org (tarox.wildebeest.org [172.31.17.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id DF3553000A21; Sat, 6 Jun 2020 16:05:15 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 9339D413CC40; Sat, 6 Jun 2020 16:05:15 +0200 (CEST) Message-ID: Subject: Re: location list From: Mark Wielaard To: Sasha Da Rocha Pinheiro , "elfutils-devel@sourceware.org" Date: Sat, 06 Jun 2020 16:05:15 +0200 In-Reply-To: References: , , Content-Type: multipart/mixed; boundary="=-h1o+Nn+b5dE8cIuZasNE" X-Mailer: Evolution 3.28.5 (3.28.5-8.el7) Mime-Version: 1.0 X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: elfutils-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Elfutils-devel mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2020 14:05:19 -0000 --=-h1o+Nn+b5dE8cIuZasNE Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Sasha, On Sat, 2020-06-06 at 00:30 +0000, Sasha Da Rocha Pinheiro wrote: > As you can see the following variables have distinct locations: > [ 81] variable abbrev: 5 > name (string) "a" > decl_file (data1) sasha.c (1) > decl_line (data1) 12 > type (ref4) [ cd] > location (sec_offset) location list > [ 0] > [ 9f] variable abbrev: 5 > name (string) "g" > decl_file (data1) sasha.c (1) > decl_line (data1) 15 > type (ref4) [ cd] > location (sec_offset) location list > [ 4a] > [ bd] variable abbrev: 5 > name (string) "z" > decl_file (data1) sasha.c (1) > decl_line (data1) 16 > type (ref4) [ cd] > location (sec_offset) location list > [ 6e] >=20 > But when I use the code I sent before to list the three variables, I > always get: >=20 > [main01.cpp:73] - Variable and location found (a), size(1). > [main01.cpp:78] - interval: (0x0,0x5)=20 > [main01.cpp:78] - interval: (0x5,0xa)=20 > [main01.cpp:78] - interval: (0x16,0x24)=20 > [main01.cpp:73] - Variable and location found (g), size(1). > [main01.cpp:78] - interval: (0x0,0x5)=20 > [main01.cpp:78] - interval: (0x5,0xa)=20 > [main01.cpp:78] - interval: (0x16,0x24)=20 > [main01.cpp:73] - Variable and location found (z), size(1). > [main01.cpp:78] - interval: (0x0,0x5)=20 > [main01.cpp:78] - interval: (0x5,0xa)=20 > [main01.cpp:78] - interval: (0x16,0x24)=20 >=20 >=20 > No matter the locationAttribute the code always get the first > location descriptors in .debug_loc:=20 > =20 > DWARF section [ 7] '.debug_loc' at offset 0x1c6: >=20 > CU [ b] base: .text+000000000000000000
> [ 0] range 0, 5 > .text+000000000000000000
.. > .text+0x0000000000000004 > [ 0] lit0 > [ 1] stack_value > range 5, a > .text+0x0000000000000005 .. > .text+0x0000000000000009 > [ 0] reg1 > range 16, 24 > .text+0x0000000000000016 .. > .text+0x0000000000000023 > [ 0] reg1 > [ 4a] range 0, 5 > .text+000000000000000000
.. > .text+0x0000000000000004 > [ 0] lit0 > [ 1] stack_value > [ 6e] range 5, a > .text+0x0000000000000005 .. > .text+0x0000000000000009 > [ 0] lit0 > [ 1] stack_value > range a, e > .text+0x000000000000000a .. > .text+0x000000000000000d > [ 0] const4u 65537 > [ 5] breg0 0 > [ 7] minus > [ 8] stack_value I think I see what is happening. The fact that
is at .text+000000000000000000 suggests that this is actually an ET_REL file (not linked object file). The libdw dwarf_xxx calls don't do relocations. But eu-readelf does. So while eu-readelf shows some offsets as their relocated values, your program just using dwarf_xxx calls does not. Specifically the DW_AT_location list attributes will all point to zero. Which explains why every location list seems to be the same. We don't have a public function to just apply all relocations to an object file, but opening the file through dwfl_begin () will do it. Something like the attached. Hope that helps, Mark --=-h1o+Nn+b5dE8cIuZasNE Content-Disposition: inline; filename="dwfl_dwarf.c" Content-Type: text/x-csrc; name="dwfl_dwarf.c"; charset="UTF-8" Content-Transfer-Encoding: base64 LyogUHJpbnQgYWxsIGxvY2F0aW9ucyBpbiB0aGUgd2hvbGUgRElFIHRyZWUgb2YgYSBzaW5nbGUg ZmlsZSB1c2luZwogICBkd2ZsIHRvIGhhbmRsZSBFVF9SRUwgZmlsZXMgKHdoaWNoIG5lZWQgdGhl IC5kZWJ1ZyBzZWN0aW9ucyB0byBiZQogICByZWxvY2F0ZWQpIGFuZCB0byBhdXRvbWF0aWNhbGx5 IGdldCBzZXBhcmF0ZSBkZWJ1Z2luZm8uCgogICBnY2MgLVdhbGwgLVdleHRyYSAtZyAtTzIgLW8g ZHdmbF9kd2FyZiBkd2ZsX2R3YXJmLmMgLWxkdwoqLwoKLyogV2Ugd2FudCB0aGUgc2FuZSBiYXNl bmFtZSBmdW5jdGlvbi4gKi8KI2RlZmluZSBfR05VX1NPVVJDRQojaW5jbHVkZSA8c3RyaW5nLmg+ CiNpbmNsdWRlIDxzdGRib29sLmg+CiNpbmNsdWRlIDxzdGRpby5oPgojaW5jbHVkZSA8aW50dHlw ZXMuaD4KCiNpbmNsdWRlIDxkd2FyZi5oPgojaW5jbHVkZSA8ZWxmdXRpbHMvbGliZHcuaD4KI2lu Y2x1ZGUgPGVsZnV0aWxzL2xpYmR3ZmwuaD4KCnZvaWQKaGFuZGxlX2RpZSAoRHdhcmZfRGllICpk aWUpCnsKICBkbwogICAgewogICAgICBEd2FyZl9BdHRyaWJ1dGUgYXR0cjsKICAgICAgaWYgKChk d2FyZl9hdHRyIChkaWUsIERXX0FUX2xvY2F0aW9uLCAmYXR0cikgIT0gTlVMTCkpCgl7CgkgIHBy aW50ZiAoIlslIiBQUkl4NjQgIl0iLCBkd2FyZl9kaWVvZmZzZXQgKGRpZSkpOwoJICBwdHJkaWZm X3Qgb2ZmID0gMDsKCSAgRHdhcmZfQWRkciBiYXNlLCBzdGFydCwgZW5kOwoJICBkbwoJICAgIHsK CSAgICAgIER3YXJmX09wICpleHByOwoJICAgICAgc2l6ZV90IGV4cHJsZW47CgkgICAgICBvZmYg PSBkd2FyZl9nZXRsb2NhdGlvbnMoJmF0dHIsIG9mZiwgJmJhc2UsICZzdGFydCwgJmVuZCwKCQkJ CSAgICAgICAmZXhwciwgJmV4cHJsZW4pOwoJICAgICAgaWYgKG9mZiA+IDApCgkJcHJpbnRmICgi KCUiIFBSSXg2NCAiLCUiIFBSSXg2NCAiKVslemRdICIsCgkJCXN0YXJ0LCBlbmQsIGV4cHJsZW4p OwoJICAgIH0KCSAgd2hpbGUgKG9mZiA+IDApOwoJICBwcmludGYgKCJcbiIpOwoJfQoKICAgICAg RHdhcmZfRGllIGNoaWxkOwogICAgICBpZiAoZHdhcmZfY2hpbGQgKGRpZSwgJmNoaWxkKSA9PSAw KQoJaGFuZGxlX2RpZSAoJmNoaWxkKTsKICAgIH0KICB3aGlsZSAoZHdhcmZfc2libGluZ29mIChk aWUsIGRpZSkgPT0gMCk7Cn0KCnN0YXRpYyBjb25zdCBEd2ZsX0NhbGxiYWNrcyBkd2ZsX2NhbGxi YWNrcyA9CiAgewogICAgLmZpbmRfZGVidWdpbmZvID0gZHdmbF9zdGFuZGFyZF9maW5kX2RlYnVn aW5mbywKICAgIC5zZWN0aW9uX2FkZHJlc3MgPSBkd2ZsX29mZmxpbmVfc2VjdGlvbl9hZGRyZXNz LAogICAgLmZpbmRfZWxmID0gZHdmbF9idWlsZF9pZF9maW5kX2VsZiwKICB9OwoKaW50IG1haW4g KGludCBhcmdjLCBjaGFyICoqYXJndikKewogIGlmIChhcmdjID09IDIpCiAgICB7CiAgICAgIGNv bnN0IGNoYXIgKmZpbGUgPSBhcmd2WzFdOwogICAgICBjb25zdCBjaGFyICpiYXNlID0gYmFzZW5h bWUgKGZpbGUpOwogICAgICAvKiBDcmVhdGUgYSBvbmUgZWxmIG1vZHVsZSBmaWxlIER3ZmwuICov CiAgICAgIER3ZmwgKmR3ZmwgPSBkd2ZsX2JlZ2luICgmZHdmbF9jYWxsYmFja3MpOwogICAgICBk d2ZsX3JlcG9ydF9iZWdpbiAoZHdmbCk7CiAgICAgIER3ZmxfTW9kdWxlICptb2QgPSBkd2ZsX3Jl cG9ydF9lbGYgKGR3ZmwsIGJhc2UsIGZpbGUsIC0xLCAwLCB0cnVlKTsKICAgICAgZHdmbF9yZXBv cnRfZW5kIChkd2ZsLCBOVUxMLCBOVUxMKTsKCiAgICAgIER3YXJmX0FkZHIgYmlhczsKICAgICAg RHdhcmYgKmRiZyA9IGR3ZmxfbW9kdWxlX2dldGR3YXJmKG1vZCwgJmJpYXMpOwogICAgICBpZiAo ZGJnICE9IE5VTEwpCgl7CgkgICAvKiBTaG91bGQgYmUgemVybyB3aXRoIG9uZSBtb2R1bGUuICov CgkgIHByaW50ZiAoImJpYXM6ICUiIFBSSXg2NCAiXG4iLCBiaWFzKTsKCSAgRHdhcmZfQ1UgKmN1 ID0gTlVMTDsKCSAgRHdhcmZfSGFsZiB2ZXJzaW9uOwoJICBEd2FyZl9EaWUgY3VkaWUsIHN1YmRp ZTsKCSAgdWludDhfdCB1bml0X3R5cGU7CgkgIHdoaWxlIChkd2FyZl9nZXRfdW5pdHMgKGRiZywg Y3UsICZjdSwgJnZlcnNpb24sICZ1bml0X3R5cGUsCgkJCQkgICZjdWRpZSwgJnN1YmRpZSkgPT0g MCkKCSAgICBoYW5kbGVfZGllICgmY3VkaWUpOwoJfQogICAgICBkd2ZsX2VuZCAoZHdmbCk7CiAg ICB9Cn0K --=-h1o+Nn+b5dE8cIuZasNE--