From owner-freebsd-current@freebsd.org Fri Jan 27 21:31:35 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 73E60CC4726 for ; Fri, 27 Jan 2017 21:31:35 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 50DBA23D for ; Fri, 27 Jan 2017 21:31:35 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 50316CC4725; Fri, 27 Jan 2017 21:31:35 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4FD91CC4724 for ; Fri, 27 Jan 2017 21:31:35 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qt0-x244.google.com (mail-qt0-x244.google.com [IPv6:2607:f8b0:400d:c0d::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0958E23A; Fri, 27 Jan 2017 21:31:35 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: by mail-qt0-x244.google.com with SMTP id n13so48701233qtc.0; Fri, 27 Jan 2017 13:31:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version; bh=abOyMIBsk/mIcTUNFhLY36kbxsPErmnOdyvKRAP3AkQ=; b=b1JtCWWULlvJgTpmlSvUS8gbM4c6p6d95ietmSecxxezjA8UPvmVWJ+INP1Jt4vKJE VxFJaL7THTfTRu8I+4HpHSuO4g+TpJrGZG9rq9NozBSxEGRWohCWcVZfZA1MTwixALpV rOG8U1IOEZ1lIOZFO+ycg4pxP5Lskbc3ECSNhr2A/4uUqtTDLk57+u6yBTB+laxiLBPJ KYRe2nb0GerRi9x4caV0Qo+ymTzKEU8RhIJZEkMPbGH0PhKSgUJ4mTq6uVwxb3SDPBAx GYE0AlsGCIrcVYx7oGUdU0PdA0ozfzVcGmPoTseqcBfhphrZ7oZ1pi27nXsRRTLFyCwm rtfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version; bh=abOyMIBsk/mIcTUNFhLY36kbxsPErmnOdyvKRAP3AkQ=; b=Ec/sRKLSfsOm+hkIc5sQGJ9Ro8c2RgWO4pgo28Xqi2HuXp3LOQP4VKfDiqbLfJPIe9 ETrlG8CEbq+oGJOK0VpARCrvwRG3kKX73h6+I7s749yRx1+HjIJiBAuicw6cmuI1s9e2 yOkSk0lp59spsO5fMjrjIohPUxi/jmD8cgOty6iS6MUVwlZu3I3FyG74iub5JuIbSek8 ChKTvdyK7AHO3Ajs9cBpI3lcjJs/jjCBiaMPGdzSLZrNvjOTNhQblvQcStcZtnNXdTYH 7DE4U8nqbnOKNmFQNjYsgdoahyzjtdvg1PXpFM6WtszvXOSDETaK/Xr3jmrZftGsXwsP dJXA== X-Gm-Message-State: AIkVDXIIexv1Cqh/cG3LYUaMD66auTW+L8gTqn5YJAKzugnzAFmfbKm68dnlhg5OQNKyhw== X-Received: by 10.237.62.68 with SMTP id m4mr9734870qtf.171.1485552694018; Fri, 27 Jan 2017 13:31:34 -0800 (PST) Received: from kan ([2601:18f:802:4680:226:18ff:fe00:232e]) by smtp.gmail.com with ESMTPSA id w138sm5142944qka.27.2017.01.27.13.31.33 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 27 Jan 2017 13:31:33 -0800 (PST) Date: Fri, 27 Jan 2017 16:31:28 -0500 From: Alexander Kabaev To: Don Lewis 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> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/xtyL5eBxqByNOU1+xb3aTM5"; protocol="application/pgp-signature" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2017 21:31:35 -0000 --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 wrote: > On 27 Jan, Alexander Kabaev wrote: > > On Fri, 27 Jan 2017 00:31:30 -0800 (PST) > > Don Lewis 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 > 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 > 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: > . > Find the GDB manual and other documentation resources online at: > . > 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--