Date: Fri, 27 Jan 2017 16:31:28 -0500 From: Alexander Kabaev <kabaev@gmail.com> To: Don Lewis <truckman@FreeBSD.org> Cc: current@FreeBSD.org Subject: Re: malloc() call somehow calling the rtld malloc() implementaion Message-ID: <20170127163128.46678e8b@kan> In-Reply-To: <201701271847.v0RIlKiB020727@gw.catspoiler.org> References: <20170127121916.6d675d26@kan> <201701271847.v0RIlKiB020727@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/xtyL5eBxqByNOU1+xb3aTM5
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
On Fri, 27 Jan 2017 10:47:20 -0800 (PST)
Don Lewis <truckman@FreeBSD.org> wrote:
> On 27 Jan, Alexander Kabaev wrote:
> > On Fri, 27 Jan 2017 00:31:30 -0800 (PST)
> > Don Lewis <truckman@FreeBSD.org> wrote: =20
>=20
> >> If I create a simple test program that calls malloc() and set a
> >> breakpoint in malloc(), the breakpoint gets set in the rtld
> >> version, but the the libc version of malloc is what gets called.
> >>=20
> >> What the heck is going on here, and how can I fix it?
> >> =20
> >=20
> > rtld on my system does not have malloc exposed as dynamic symbol, it
> > cannot possibly be used for symbol resolution by any outside
> > module. =20
>=20
> Same here, but gdb at least seems to find it anyway.
>=20
> 12.0-CURRENT r311765M
>=20
> %nm /libexec/ld-elf.so.1
> nm: /libexec/ld-elf.so.1: no symbols
>=20
> %elfdump -s /libexec/ld-elf.so.1 | grep st_name | sort
> st_name:=20
> st_name:=20
> st_name: FBSD_1.0
> st_name: FBSD_1.1
> st_name: FBSD_1.2
> st_name: FBSD_1.3
> st_name: FBSD_1.4
> st_name: FBSD_1.5
> st_name: FBSDprivate_1.0
> st_name: __tls_get_addr
> st_name: _r_debug_postinit
> st_name: _rtld_addr_phdr
> st_name: _rtld_allocate_tls
> st_name: _rtld_atfork_post
> st_name: _rtld_atfork_pre
> st_name: _rtld_error
> st_name: _rtld_free_tls
> st_name: _rtld_get_stack_prot
> st_name: _rtld_is_dlopened
> st_name: _rtld_thread_init
> st_name: dl_iterate_phdr
> st_name: dladdr
> st_name: dlclose
> st_name: dlerror
> st_name: dlfunc
> st_name: dlinfo
> st_name: dllockinit
> st_name: dlopen
> st_name: dlsym
> st_name: dlvsym
> st_name: fdlopen
> st_name: r_debug_state
>=20
> %cd /tmp
> zipper:/tmp 508%cat malloctest.c=20
> #include <stdlib.h>
> volatile void *p;
> int
> main(void) {
> p =3D malloc(16);
> }
> %cc -g malloctest.c
> %gdb a.out
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and
> you are welcome to change it and/or distribute copies of it under
> certain conditions. Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for
> details. This GDB was configured as "amd64-marcel-freebsd"...
> (gdb) break main
> Breakpoint 1 at 0x40076b: file malloctest.c, line 5.
> (gdb) run
> Starting program: /tmp/a.out=20
>=20
> Breakpoint 1, main () at malloctest.c:5
> 5 p =3D malloc(16);
> Current language: auto; currently minimal
> (gdb) break malloc
> Breakpoint 2 at 0x80060e9a4: file /usr/src/libexec/rtld-elf/malloc.c,
> line 163. (gdb) cont
> Continuing.
>=20
> Program exited normally.
> (gdb) quit
>=20
> Ports gdb finds both the rtld malloc() and the libc malloc():
>=20
> %/usr/local/bin/gdb a.out
> GNU gdb (GDB) 7.12 [GDB v7.12 for FreeBSD]
> Copyright (C) 2016 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>; This is free software: you are
> free to change and redistribute it. There is NO WARRANTY, to the
> extent permitted by law. Type "show copying" and "show warranty" for
> details. This GDB was configured as "x86_64-portbld-freebsd12.0".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
> <http://www.gnu.org/software/gdb/documentation/>.
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from a.out...done.
> (gdb) break main
> Breakpoint 1 at 0x40076b: file malloctest.c, line 5.
> (gdb) run
> Starting program: /tmp/a.out=20
>=20
> Breakpoint 1, main () at malloctest.c:5
> 5 p =3D malloc(16);
> (gdb) break malloc
> Breakpoint 2 at 0x80060e9a4: malloc. (2 locations)
> (gdb) cont
> Continuing.
>=20
> Breakpoint 2, __malloc (size=3D16) at jemalloc_jemalloc.c:1636
> 1636 size_t usize JEMALLOC_CC_SILENCE_INIT(0);
gdb looks into debugging info for symbols in debug information and so
has greater visibility. Symbols gdb sees play no role in dynasmic
building, so rtld malloc somehow replacing the malloc from the program
as you suspected is really impossible.
kib@ has a better idea that is worth investigating further: is the
address on which idlc traps corresponds to TLS storage? tls alloc calls
are supposed to respect the tls section alignment though.
--=20
Alexander Kabaev
--Sig_/xtyL5eBxqByNOU1+xb3aTM5
Content-Type: application/pgp-signature
Content-Description: Цифровая подпись OpenPGP
-----BEGIN PGP SIGNATURE-----
iQKTBAEBCgB9FiEExffZlZm2QeE8UVaRBxMimZJ5Ln4FAliLvDBfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEM1
RjdEOTk1OTlCNjQxRTEzQzUxNTY5MTA3MTMyMjk5OTI3OTJFN0UACgkQBxMimZJ5
Ln6qig//RYWDtUThKvZ7So5KojW6THOUUFAQ+WhN7tc9H+jv7nXDoHtZ7gVSnpYR
TOdnw1paNTwijRMljLfrH1EueJWi4AFJZHSz6nfiCJJOS9sowLpfzgCH/Dp1xPHr
eM4vnJfWpR9CTJ7nyPUi9pzDDMOujzqT2BxjDKKq8v0lenMl7Z8RV31yqLgyXOVZ
skLD9m4aIrV3hrT4G3EZAN+2I9f9WF4YNxj1lFnNMyabKzGXRHSXkd6TI7OdRlKP
43Ctc4GmrWC7+NrrVFS3oA/taPPB+pBuLgmBXCllx5D6BbpueZ4iLOBtJPd67kLB
1TMpVv8Qjqs/K3BxFS6Aud6aopF+CxD29nGu04Nqs2uTPbfloLzHuVBBb8soYI7v
cNvNUbX7qID1PDAVahQS5Q7kqE79F9m6I2Fq2WibJ5exdjYY0Hj2wRupYQVpgv4t
V3YOcKf1k78QpkqipNcHeVYJroTPeWc1dL/exxM29jcXlqKXVMvXvmzA3xC5Hz9d
WL9UP4eeWLYg9Q2CCkRGGVaLU+uEGNgEwuTPKiHKHlTK265642UbcWvQMOPzgLo3
ekyIL/WD6y3wX1+XSZFQblENkBGjMwevwNQqIk2BHVdeNwVJ9auNq4MDXqlxrKfd
0flvTIgsZWdddSdC3j8ucX1+/3JCum1U84zY6GqXfiNpDTjIndE=
=Ty83
-----END PGP SIGNATURE-----
--Sig_/xtyL5eBxqByNOU1+xb3aTM5--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170127163128.46678e8b>