From mboxrd@z Thu Jan  1 00:00:00 1970
Content-Type: multipart/mixed; boundary="===============7349958941251185469=="
MIME-Version: 1.0
From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: elfutils-devel@lists.fedorahosted.org
Subject: [commit] [PATCH 2/2] Support note NT_FILE for locating files.
Date: Fri, 26 Sep 2014 22:45:31 +0200
Message-ID: <20140926204531.GA25264@host2.jankratochvil.net>
In-Reply-To: 1411481098.27706.41.camel@bordewijk.wildebeest.org

--===============7349958941251185469==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

On Tue, 23 Sep 2014 16:04:58 +0200, Mark Wielaard wrote:
> On Tue, 2014-09-09 at 23:00 +0200, Jan Kratochvil wrote:
> > tests/test-core.core.bz2 had to have its NT_FILE disabled as run-unstri=
p-n.sh
> > otherwise FAILs:
> > FAIL: 0x7f67f2aaf000+0x202000 - . - /home/jkratoch/redhat/elfutils-libr=
egr/test-core-lib.so
> > PASS: 0x7f67f2aaf000+0x202000 - . - test-core-lib.so
> > As test-core-lib.so is found in link_map but it is not present on the d=
isk
> > elfutils now chooses the more reliable filename from NT_FILE (although =
that
> > filename is also not found on the disk).  Updating the expected text wo=
uld be
> > also sufficient.
> =

> I think it is better to just change the expected text instead of
> updating the binary core file.

Done.  Just the testcase now unsuccessfully does:
	open("/home/jkratoch/redhat/elfutils-libregr/test-core-lib.so", O_RDONLY) =
=3D -1 ENOENT (No such file or directory)
and it may have some unexpected result if such file exists (sure unlikely).


> > +/* Return whether there is SZ bytes available at PTR till END.
> > +   Function comes from src/readelf.c .  */
> =

> function is small enough that comment where it came from is not really
> necessary.

Done.


> Just pass in the ei_data byte since that is all you are using.

Done.


> Same here. Just pass in the ei_class (or ptrsize) and ei_data or a
> pointer to the e_ident and use that.

Done.


> > +testrun ${abs_top_builddir}/src/stack --core=3Dlinkmap-cut.core -e lin=
kmap-cut >bt || true
> > +cat bt
> > +grep -qw libfunc bt
> > +grep -qw main bt
> =

> Maybe you want to use -m to check it got the module name correct?

OK, used that and updated the match:
	grep -q '^#0  0x00007f08bc24d681 libfunc - .//////////////////////////////=
//////linkmap-cut-lib\.so$' bt
	grep -q '^#1  0x00000000004006b4 main - linkmap-cut$' bt


> The NT_FILE notes seem to have lots of slashed in them, is that
> deliberate?

There is always absolute filename from Linux kernel.  That would never work=
 for
a testcase, therefore I had to patch the bytes by hexedit from absolute
pathname to a relative one:
      7f08bc24d000-7f08bc24e000 00000000 4096        /home/jkratoch/redhat/=
elfutils/tests/linkmap-cut-lib.so
->
      7f08bc24d000-7f08bc24e000 00000000 4096        ./////////////////////=
///////////////linkmap-cut-lib.so


> The comments don't say how the binaries were generated,
> please add that in case someone wants to regenerate them one day.

I agree, added:
	# The core file has patched:
	# * _r_debug.r_map.l_next.l_next (vma 0x3fdf621718, offset 0x7718) =3D NUL=
L,
	#   therefore all libraries after the main executable and vDSO are removed.
	# * NT_FILE absolute filenames are relativized to: ./////basename


Checked in:
	6d48bbf406851b56920582b8ce29db13ad4f4e2e


Thanks,
Jan

--===============7349958941251185469==
Content-Type: message/rfc822
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.mht"

WzxlbWFpbC5tZXNzYWdlLk1lc3NhZ2UgaW5zdGFuY2UgYXQgMHgxNTM5MjAwPl0=
--===============7349958941251185469==--