From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 7 06:12:40 2013
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Delivered-To: freebsd-hackers@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTP id 88C6CE4C;
Thu, 7 Nov 2013 06:12:40 +0000 (UTC)
(envelope-from kostikbel@gmail.com)
Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id 0D03B2D65;
Thu, 7 Nov 2013 06:12:39 +0000 (UTC)
Received: from tom.home (kostik@localhost [127.0.0.1])
by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id rA76CYbA067753;
Thu, 7 Nov 2013 08:12:34 +0200 (EET)
(envelope-from kostikbel@gmail.com)
DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua rA76CYbA067753
Received: (from kostik@localhost)
by tom.home (8.14.7/8.14.7/Submit) id rA76CYPs067752;
Thu, 7 Nov 2013 08:12:34 +0200 (EET)
(envelope-from kostikbel@gmail.com)
X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com
using -f
Date: Thu, 7 Nov 2013 08:12:34 +0200
From: Konstantin Belousov <kostikbel@gmail.com>
To: Mark Johnston <markj@freebsd.org>
Subject: Re: dl_iterate_phdr() omits ld-elf.so
Message-ID: <20131107061234.GO59496@kib.kiev.ua>
References: <20131106052010.GB2826@raichu> <20131106171301.GG59496@kib.kiev.ua>
<20131106231352.GB86666@charmander.sandvine.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="xQILpJsL5cebVBoz"
Content-Disposition: inline
In-Reply-To: <20131106231352.GB86666@charmander.sandvine.com>
User-Agent: Mutt/1.5.22 (2013-10-16)
X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00,
DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no
version=3.3.2
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home
Cc: freebsd-hackers@freebsd.org
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
<freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-hackers>,
<mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
<mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Nov 2013 06:12:40 -0000
--xQILpJsL5cebVBoz
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Nov 06, 2013 at 06:13:52PM -0500, Mark Johnston wrote:
> On Wed, Nov 06, 2013 at 07:13:01PM +0200, Konstantin Belousov wrote:
> > On Wed, Nov 06, 2013 at 12:20:10AM -0500, Mark Johnston wrote:
> > > Hello,
> > >=20
> > > While experimenting with dl_iterate_phdr(3), I noticed that it doesn't
> > > include the runtime linker itself in the list of objects. This is
> > > inconsistent with related interfaces such as <pid>/map in procfs, and
> > > kinfo_getvmmap(3), so it seems incorrect to me that rtld is excluded
> > > from the list of callback arguments.
> > >=20
> > > Is there a reason for this behaviour? If not, does anyone have though=
ts
> > > on the diff below which fixes this?
> > >=20
> > > Thanks,
> > > -Mark
> > >=20
> > > diff --git a/libexec/rtld-elf/rtld.c b/libexec/rtld-elf/rtld.c
> > > index fa6dc2a..b55effa 100644
> > > --- a/libexec/rtld-elf/rtld.c
> > > +++ b/libexec/rtld-elf/rtld.c
> > > @@ -3269,6 +3269,11 @@ dl_iterate_phdr(__dl_iterate_hdr_callback call=
back, void *param)
> > > break;
> > > =20
> > > }
> > > + if (error =3D=3D 0) {
> > > + rtld_fill_dl_phdr_info(&obj_rtld, &phdr_info);
> > > + error =3D callback(&phdr_info, sizeof(phdr_info), param);
> > > + }
> > > +
> > > lock_release(rtld_bind_lock, &bind_lockstate);
> > > lock_release(rtld_phdr_lock, &phdr_lockstate);
> >=20
> > I cannot make a case where this patch would be problematic, but rtld is
> > very special object in the process address space indeed. The patch is
> > needed exactly because rtld is not included into the list of the loaded
> > objects, and more, symbol resolution from rtld is a special case. Doing
> > dlopen() on rtld path would probably break things in funny way.
> >=20
> > Still, I think the patch is worth committing, but be prepared to handle
> > the broken cases, which could come out in quite indirect ways.
> >=20
> > BTW, why do you need this ?
>=20
> I was just trying to find a portable way to figure out the address at
> which a given object was located, and noticed the omission because the
> runtime linker is included in the list on Linux. It seemed like a bug to
> me just based on what dl_iterate_phdr(3) is supposed to do: invoke a
> callback for each loaded ELF object, which includes rtld even though
> it's special.
>=20
> So I don't really need this change. In this case, do you still think
> it's worth committing? Or should I just leave it alone?
It seems to make the function more logical. As I said, I think that the
patch is worth committing.
--xQILpJsL5cebVBoz
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (FreeBSD)
iQIcBAEBAgAGBQJSey9RAAoJEJDCuSvBvK1BCZUQAKEdzw4UFVa/0oVbv977JK5U
E4P295B3YvMEJuIEijWhrdPacrhzS0xGY+EvLZj5KME7wNduBV/dSFCxlFjtnMvm
zubNW4YQQbW4+ZCDUEUKuIR9vcdvle8cVoo+RfoXGKPu4MtfZ5Fpj8cL1wmzu3cr
B3cZy2XM0RI7GhJfxXgLvFDW71Qjuxw/AYrod9hbI0rHEsXGbhF5ROjcUMzIe4VF
v4FJJdYd4mqxZ6lHCdHOrkhMwL59BXFl2ANXAZZNZGi8J2cB+ZktCI7g/8w4ooTo
nI7DlSrLb36Lp5N5KJoKJwmHYUpDYBeFnB62yu2xbKX4Y4QbWRQKlbuQtSTn/4iw
eTLUu4zr0bHcLihRGnGumKOY2vT/9alOmAHSJfI64Acmsli06rHOiRdMY/Jc8rr7
325Ifmeuu5IkWltKvYJ4vYBIBTkis8hT2lHif2IFcFxKk4KzvhVGLhT22A2qVrO8
aafxyuWZJxRMHlPYVfzSv8JDZvvCJqZW6HeOvjW1P5efyrlPCXmB/2FYoprJL5rT
uqrQ/YycIKCVBjuatau37oo2uIVAVvvmPK+ZQHoR/smrGi1JxMr7ru5haAYWZL2N
9azmaKxE5KJQVA/X1w7IsWrqS+ll4lPZ53TCcRxAljupdQdb2ry/UQ7fvViuys9L
DFHCY7PmtLAnZ95M+0dC
=Uke4
-----END PGP SIGNATURE-----
--xQILpJsL5cebVBoz--