Date: Thu, 7 Nov 2013 08:12:34 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Mark Johnston <markj@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: dl_iterate_phdr() omits ld-elf.so Message-ID: <20131107061234.GO59496@kib.kiev.ua> In-Reply-To: <20131106231352.GB86666@charmander.sandvine.com> References: <20131106052010.GB2826@raichu> <20131106171301.GG59496@kib.kiev.ua> <20131106231352.GB86666@charmander.sandvine.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131107061234.GO59496>