From owner-freebsd-hackers@freebsd.org Sun Jan 14 00:47:17 2018 Return-Path: Delivered-To: freebsd-hackers@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 1D803E64564 for ; Sun, 14 Jan 2018 00:47:17 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 98E6680AD2 for ; Sun, 14 Jan 2018 00:47:16 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from coleburn.home.andric.com (coleburn.home.andric.com [192.168.0.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id B5D8947253; Sun, 14 Jan 2018 01:47:13 +0100 (CET) From: Dimitry Andric Message-Id: <6ED2FBBD-8404-4979-BC4B-559AE5229B3B@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_3447DD2F-7FA3-4DAE-9CFE-CFD3CAAB8FB8"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FreeBSD 11.1 + Clang 4.0 + PHP source = Core dumps Date: Sun, 14 Jan 2018 01:47:13 +0100 In-Reply-To: Cc: freebsd-hackers@freebsd.org To: J David References: X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jan 2018 00:47:17 -0000 --Apple-Mail=_3447DD2F-7FA3-4DAE-9CFE-CFD3CAAB8FB8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 14 Jan 2018, at 00:24, J David wrote: >=20 > Starting with Clang 4.0 on FreeBSD 11.1 we are seeing really odd > behavior and crashes on a version of PHP that we compile in house. > It=E2=80=99s not clear if this is a compiler bug, or what exactly is > happening. >=20 > For example, this code (from PHP=E2=80=99s intl extension) core dumps: >=20 > U_CFUNC TimeZone *timezone_process_timezone_argument(zval = *zv_timezone, > intl_error = *outside_error, > const char *func) > { > zval local_zv_tz; > char *message =3D NULL; > TimeZone *timeZone; >=20 > if (zv_timezone =3D=3D NULL || Z_TYPE_P(zv_timezone) =3D=3D = IS_NULL) { > timelib_tzinfo *tzinfo =3D get_timezone_info(); > ZVAL_STRING(&local_zv_tz, tzinfo->name); > zv_timezone =3D &local_zv_tz; > } else { > ZVAL_NULL(&local_zv_tz); > } >=20 > if (Z_TYPE_P(zv_timezone) =3D=3D IS_OBJECT && > instanceof_function(Z_OBJCE_P(zv_timezone), = TimeZone_ce_ptr)) { >=20 > If zv_timezone is passed in as a NULL pointer, this code core dumps on > the =E2=80=9Cif (Z_TYPE_P(zv_timezone)=E2=80=9D and gdb says that = zv_timezone is NULL. > But if you look immediately above, if zv_timezone is NULL it is set to > another value. >=20 > If you add a printf of the zv_timezone pointer above the second if > block, it will show that zv_timezone is no longer NULL (because it was > just set to &local_zv_tz), and the program will no longer crash. >=20 > This crash can also be =E2=80=9Cfixed=E2=80=9D by placing the = following line (a memory > barrier) above the second if statement: >=20 > __asm__ volatile(=E2=80=9C" : : : "memory"); >=20 > Although that addresses this one, it seems like there may be a number > of other similar issues throughout the PHP code base. >=20 > This just can=E2=80=99t be right; that should not be necessary. = What=E2=80=99s going on? >=20 > Is this a bug in clang? Is PHP doing something dodgy? User error on > our part? We don=E2=80=99t see this behavior compiling the same = source with > clang 3.x / FreeBSD 10.x. I suspect that you need to add -fno-strict-aliasing to your compilation flags, if you haven't already. =46rom a cursory look, PHP seems to use = a *lot* of aliasing and type punning. -Dimitry --Apple-Mail=_3447DD2F-7FA3-4DAE-9CFE-CFD3CAAB8FB8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCWlqokQAKCRCwXqMKLiCW o8QqAJ4qZxilGT92p+cqkMzUrYs1wihXwwCgpZIWxuuPDE1Vo3SzDx1aFm69PYw= =V07W -----END PGP SIGNATURE----- --Apple-Mail=_3447DD2F-7FA3-4DAE-9CFE-CFD3CAAB8FB8-- From owner-freebsd-hackers@freebsd.org Sun Jan 14 15:57:02 2018 Return-Path: Delivered-To: freebsd-hackers@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 AAA68E774E5 for ; Sun, 14 Jan 2018 15:57:02 +0000 (UTC) (envelope-from chuck@tuffli.net) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 7F40F812AB for ; Sun, 14 Jan 2018 15:57:02 +0000 (UTC) (envelope-from chuck@tuffli.net) Received: by mail-io0-x229.google.com with SMTP id f34so5406439ioi.13 for ; Sun, 14 Jan 2018 07:57:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tuffli-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=zGunf/N2zgVytLyC3X7jMJuwMp9Kw3lVV1qmrEV+KnM=; b=ST8euZpizVmYUW3eSA4izmeX/zF1Zfl4mVUR8aCfDC+0p5BPHNr3hdMZDGRfCpXwfo p9OwUsydU/9nSjISvOmlJyjLJtfd9CK7y5tNpktA/YxbMRYUzQRWJUUejrK9RJ7w8mqc kBiuYGdO9J4kAN53MVXmER/bEBcjubdPML/pMy7X3G5JjE1Dxwy+zAWHcby5DzZXXMZY udQp4Png55J51iTCSUwHlONZTzMQrcUTNxp8hsD1w3F5VTkRcqQMzrT3czK3wG2LeCs/ LGJ5yZo/QSEm1pf+aS/055xqsjuHpBijSfyQQrkEcuBZaO9YlhYRvLgUukPEiY5ZHndy ZIFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=zGunf/N2zgVytLyC3X7jMJuwMp9Kw3lVV1qmrEV+KnM=; b=npTfCbfR71n2wiDmZlP7QvW7SDU8W/LEdzuS/uRIrUjm9+1R5JvARuZg6xJjXycLHV l0Wp+73U3BczyfVLXrccfpt7F8GQ3hG0xwEc6NG/2iXxxOpuz7daRJ9k5p0Q3UfZkZ/4 8R9Tnmg5BX5tK7N2QKPyZzYM58U7DnReTS4oOELpcIHEudi3QMap0FcyeLuKUoOEz5UD HVDBd6zxDvK43E/+3BZJYWf6AxulbT4mn+202fkPdsdYQ8QyRBWOC/+aDdrh/ph3eGfr VvD8NaFncHdTVPem3Useekx6EUWEdR0KrKa4VIEi3BXBFIxSQzt04V4S3B3+9bgwRUUb wKbw== X-Gm-Message-State: AKwxytdWQlMeC0n3eat0P30/A55qCtnzbShOBo+DJx4eW6qo4BbCuGpy Emp8otpK2tihN/U+HmsLfpGcdMSYq/wAty0p57oLx0wYBsU= X-Google-Smtp-Source: ACJfBoucB114FrVp0eVya3yHFGBIh5JQiTVkokDnYt0MmPOYda7ywfJth14Fjpsb7PhiVW0VxEiOM1hudUrZy8z5e3I= X-Received: by 10.107.9.213 with SMTP id 82mr4971650ioj.295.1515945421463; Sun, 14 Jan 2018 07:57:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.137.76 with HTTP; Sun, 14 Jan 2018 07:57:01 -0800 (PST) From: Chuck Tuffli Date: Sun, 14 Jan 2018 07:57:01 -0800 Message-ID: Subject: examining Linux core file? To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jan 2018 15:57:02 -0000 If a Linux application running under the Linux emulation (a.k.a. Linuxulator) core dumps, is it possible to examine the resulting core file? lldb didn't seem to like it: # file mremap05.core mremap05.core: ELF 64-bit LSB core file x86-64, version 1 (FreeBSD), FreeBSD-style, from 'ases/bin/mremap05' # lldb -c mremap05.core testcases/bin/mremap05 (lldb) target create "testcases/bin/mremap05" --core "mremap05.core" error: Unable to find process plug-in for core file '/compat/linux/opt/ltp/mremap05.core' (lldb) bt error: invalid process FreeBSD's gdb seems to recognize this is as Linux, but doesn't know where to go from there: # /usr/libexec/gdb -q ./testcases/bin/mremap05 mremap05.core warning: A handler for the OS ABI "GNU/Linux" is not built into this configuration of GDB. Attempting to continue with the default i386:x86-64 settings. Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /compat/linux/opt/ltp/testcases/bin/mremap05] warning: core file may not match specified executable file. Core was generated by `./testcases/bin/mremap05'. Program terminated with signal 11, Segmentation fault. #0 0x0040eb01 in ?? () (gdb) bt #0 0x0040eb01 in ?? () Cannot access memory at address 0xdbea00 The gdb from CentOS, on the other hand, seems to think this is a FreeBSD core: # gdb -q ./testcases/bin/mremap05 mremap05.core Reading symbols from /opt/ltp/testcases/bin/mremap05...done. warning: A handler for the OS ABI "FreeBSD ELF" is not built into this configuration of GDB. Attempting to continue with the default i386:x86-64 settings. "/opt/ltp/mremap05.core": no core file handler recognizes format Are there any other approaches to consider? TIA. --chuck From owner-freebsd-hackers@freebsd.org Mon Jan 15 03:36:42 2018 Return-Path: Delivered-To: freebsd-hackers@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 2A5EBE78821 for ; Mon, 15 Jan 2018 03:36:42 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D9D387BBDB for ; Mon, 15 Jan 2018 03:36:41 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 1209190f-3b1ff700000057f2-c6-5a5c209578a5 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 1B.77.22514.5902C5A5; Sun, 14 Jan 2018 22:31:33 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id w0F3VVhg007139; Sun, 14 Jan 2018 22:31:32 -0500 Received: from mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w0F3VSMI011071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 14 Jan 2018 22:31:31 -0500 Date: Sun, 14 Jan 2018 21:31:28 -0600 From: Benjamin Kaduk To: Chuck Tuffli Cc: freebsd-hackers@freebsd.org Subject: Re: examining Linux core file? Message-ID: <20180115033127.GE72574@mit.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNIsWRmVeSWpSXmKPExsUixCmqrDtVISbKYNofQYuXR/YxWmzf/I/R gcljxqf5LB7//75iDWCK4rJJSc3JLEst0rdL4MpY0/uRseAUU8W045tZGhhbmboYOTkkBEwk Xq69y9zFyMUhJLCYSWLn68nsEM5GRolFz7ZDZc4ySazbfJEFpIVFQFXiyLJXbCA2m4CKREP3 ZWYQW0RAWaK56ykjiM0sIC/xcPsZoHoODmEBdYl9ewpBwrwCOhInt75mB7GFBAIk+hd/ZoWI C0qcnPmEBaJVS+LGv5dMIK3MAtISy/9xgJicAoESu57GglSIAi3a23eIfQKjwCwkzbOQNM9C aF7AyLyKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI10QvN7NELzWldBMjOEQl+XcwzmnwPsQowMGo xMO7YUV0lBBrYllxZe4hRkkOJiVR3ttSMVFCfEn5KZUZicUZ8UWlOanFhxglOJiVRHjDTkdE CfGmJFZWpRblw6SkOViUxHndTbSjhATSE0tSs1NTC1KLYLIyHBxKErwz5YGGChalpqdWpGXm lCCkmTg4QYbzAA2fC1LDW1yQmFucmQ6RP8VozNG28kkbM8eNF6/bmIVY8vLzUqXEeZWAiUJI AKQ0ozQPbhoozUhk7695xSgO9Jww70WQgTzAFAU37xXQKiagVfVLIkFWlSQipKQaGDUKXdQd 0u5Oey2fVnNw18bg077/DradPLshfsc2qcUX9qssOfBdsU5nBmtGyf4rT1ew2F29mzLpxhLT kptTXdnrjVZ995rodH2iSOC1rEMRd+fNiVpU+LFzttLlDM+v3ovO3BSa9WmuylYdGa3HBi/U f38/w7JK67zBwgNLBAp/t0b5mhzvOxylxFKckWioxVxUnAgAO7ffuA4DAAA= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2018 03:36:42 -0000 On Sun, Jan 14, 2018 at 07:57:01AM -0800, Chuck Tuffli wrote: > If a Linux application running under the Linux emulation (a.k.a. > Linuxulator) core dumps, is it possible to examine the resulting core > file? lldb didn't seem to like it: I wonder how a Linux gdb running under the Linuxulator would fare with it? -Ben From owner-freebsd-hackers@freebsd.org Mon Jan 15 18:51:17 2018 Return-Path: Delivered-To: freebsd-hackers@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 6811DE6EC68 for ; Mon, 15 Jan 2018 18:51:17 +0000 (UTC) (envelope-from chuck@tuffli.net) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 321F868C8F for ; Mon, 15 Jan 2018 18:51:17 +0000 (UTC) (envelope-from chuck@tuffli.net) Received: by mail-it0-x236.google.com with SMTP id w14so1305072itc.3 for ; Mon, 15 Jan 2018 10:51:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tuffli-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DFsiqByxBjhREsaoMkb867nutP/aPuuCmZlVl0hR108=; b=iEf4a830lFNJvUcr5iuiP0KeCNX28U4lHbgaL3RpU+7Oi16+3IlJuUzbWFop1bYPA4 2FESAC3EzgRYkyC7E3QlVffp+lFoZfnP0Vxczq0J1gE6fMze35KmmzQo1NSiBqO6EanK Gp/DzGg+JSFfwOG2ltirV2PuyAKvUwhXyk1buaJbuifjl/gM0Gmx8gRwRGg5Rmv/s6/N NChTjWcOQqOJocr2FzqPbIMs2DOG8EXxzXB9iydst+O3H4keRDyyC3KOuBTjM3wDWZND NxknII9rstdmF5mGvhg1oGbGZh333aQQWNsvWYRr0K0oqieJI7B0Szx10lQTYZsoc7ud 2GuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DFsiqByxBjhREsaoMkb867nutP/aPuuCmZlVl0hR108=; b=oBXuowadvJgmMqeFaWabZV5FyhhK0OX6QKE0fDsc0praQOB8QdFeQk89RXXTkGi7p6 XRBxiOALWAr+58Vc7sV15b7mNUu1jRvSfzbZ0w1Gu8J7JIl0Rn3S01+8DmDNwUhWZ4C3 jNZ+W0reYlD3URn3BM9qQTbS0ZSlDhED4LRXckLytJSXKIodq8LxjGvZ2a2gTifZj9Df x3/BxtTItLUdFBHE0cm1f8aihAFWbwJmDU5d4dfwX/JAXkTma7zGB36Ys7rHq+fS407e CJzYB8ZKW6SFoj2sCcIfY+HUD4e5Dr80WS3Gn5+ZxsWTPth7TolL7PFtgTHGZvwXwkEA gr6A== X-Gm-Message-State: AKwxytf11mwyUKiysREakfHjXaQO0aawf90mp90U2VVBDrjPsZG1Zqtk 2uPiWACH/aAuIOOA7YSkwgGMmjmPYEI4A2i5FlfBTw== X-Google-Smtp-Source: ACJfBovU4rAtz07URA7X9M0mHf196c4Lcr8+rWlQBiXSF+5NKp22Mu9nttUZ9k7kDrIgFuzN9uub5K4f/cbLF7F6Q4k= X-Received: by 10.36.66.143 with SMTP id i137mr2877606itb.30.1516042276265; Mon, 15 Jan 2018 10:51:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.137.76 with HTTP; Mon, 15 Jan 2018 10:51:15 -0800 (PST) In-Reply-To: <20180115033127.GE72574@mit.edu> References: <20180115033127.GE72574@mit.edu> From: Chuck Tuffli Date: Mon, 15 Jan 2018 10:51:15 -0800 Message-ID: Subject: Re: examining Linux core file? To: Benjamin Kaduk Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2018 18:51:17 -0000 On Sun, Jan 14, 2018 at 7:31 PM, Benjamin Kaduk wrote: > On Sun, Jan 14, 2018 at 07:57:01AM -0800, Chuck Tuffli wrote: >> If a Linux application running under the Linux emulation (a.k.a. >> Linuxulator) core dumps, is it possible to examine the resulting core >> file? lldb didn't seem to like it: > > I wonder how a Linux gdb running under the Linuxulator would fare > with it? Sorry, that's what I was trying to show with the last example. The Linux gdb from CentOS running under the Linuxulator gives: # gdb -q ./testcases/bin/mremap05 mremap05.core Reading symbols from /opt/ltp/testcases/bin/mremap05...done. warning: A handler for the OS ABI "FreeBSD ELF" is not built into this configuration of GDB. Attempting to continue with the default i386:x86-64 settings. "/opt/ltp/mremap05.core": no core file handler recognizes format --chuck From owner-freebsd-hackers@freebsd.org Tue Jan 16 01:58:39 2018 Return-Path: Delivered-To: freebsd-hackers@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 0146CEB8BD8 for ; Tue, 16 Jan 2018 01:58:39 +0000 (UTC) (envelope-from freebsd-lists@be-well.ilk.org) Received: from be-well.ilk.org (be-well.ilk.org [23.30.133.173]) by mx1.freebsd.org (Postfix) with ESMTP id D26737C8C5 for ; Tue, 16 Jan 2018 01:58:38 +0000 (UTC) (envelope-from freebsd-lists@be-well.ilk.org) Received: from lowell-desk.lan (router.lan [172.30.250.2]) by be-well.ilk.org (Postfix) with ESMTP id 86F7933D46 for ; Mon, 15 Jan 2018 20:58:30 -0500 (EST) Received: by lowell-desk.lan (Postfix, from userid 1147) id D49A23984A; Mon, 15 Jan 2018 20:58:28 -0500 (EST) From: Lowell Gilbert To: freebsd-hackers@freebsd.org Subject: Re: 1 << 31 redux References: <201801131548.w0DFmW2b045587@pdx.rh.CN85.dnsmgr.net> Date: Mon, 15 Jan 2018 20:58:27 -0500 In-Reply-To: <201801131548.w0DFmW2b045587@pdx.rh.CN85.dnsmgr.net> (Rodney W. Grimes's message of "Sat, 13 Jan 2018 07:48:32 -0800 (PST)") Message-ID: <446082sgxo.fsf@lowell-desk.lan> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2018 01:58:39 -0000 "Rodney W. Grimes" writes: > Is not this 1U<<31 -> signed value really just sweeping the bigger > issue that we are using signed values in unsigned ways? It might be more appropriate to say that we are using unsigned values, but not telling the compiler that they aren't signed. No? From owner-freebsd-hackers@freebsd.org Tue Jan 16 03:13:16 2018 Return-Path: Delivered-To: freebsd-hackers@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 63018EBF27E for ; Tue, 16 Jan 2018 03:13:16 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from sonic306-18.consmr.mail.bf2.yahoo.com (sonic306-18.consmr.mail.bf2.yahoo.com [74.6.132.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2AC9F80EA4 for ; Tue, 16 Jan 2018 03:13:15 +0000 (UTC) (envelope-from pfg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1516072388; bh=VC+vGGhEcL8goHPVCT+lsYTz6fhDSEr6U1kuiDlpodk=; h=To:From:Subject:Date:From:Subject; b=Por+kptwihPfS1O7H8wEZVvHTYKI4YFMU/GHKhlSf7CbQxAEafAPXfiDcgKOa2cY7lZQ9d5a0vJo5sfqMqa2Hh4eIkv4GogbRJmnG/7nXU75xRKFHmujr6L4GhxnXk4dUVkw3wHEqVdk1uFrzzN8VNRcmikq3oLQKgFkDvqAHO3iYLvhjQgk1YCW6Tr9ZEsDcTW70v6Qzx//KzIbowYyJRLsnRWwZHsyexz4iLIGlRbpxDo/nud7++2EZPBbMV2Iis+25ptLEPqMf2WRNm+6xQKLNt98UQ/iBXCJK78nY0FDnmXSwDrVbHVgrHFF0SakLATnb53YjS4VuxOCu5UvXg== X-YMail-OSG: qz8.gpcVM1nKAvlYOCYLfnITih1KSivF_OqA_0OuhEByYSn_G0nv8rBBMYN9O82 I170rY.svCKQSYNw4jhh.CEsxiQ5JFhyQRoloPDnbdRQ5yg.TLoC96PhCFeJa0ctYXP4DDAn4KeY VkoZjVc0EacnqjfBE2n_59fFN3wacqLo98jcGQ4oaEfn9l6OJ2n3hpMM83v_lSCmpZoeuC5BCL0R 1Hzi74dQ.J8vw1TLKrc.c.I8m.Thf5jYZ2yPiX5yfzzspAR0mqhYy70XEbsrUNYY9rN7RFfQt5zW guZ6wJGSdZilUqiVxde7DdatUVehVd7QckJx6cqinj413DsJO8mmx04z_rTfZsnQL9fHB.RIpKaB AlkZbq3jq2OrhXXiWwpy8BCVTRG.baiBdpssI_LzhE2c4DXkc6BrJv.7n9iIRxrRGrXVxGP3jS8e 2TdR_qb4WZ9CxngK4Q69IgciTFqvQJlKeCllKHSuSCOl1dafv78uOQloigys92mUoU9ACemXB Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.bf2.yahoo.com with HTTP; Tue, 16 Jan 2018 03:13:08 +0000 Received: from smtpgate102.mail.bf1.yahoo.com (EHLO [192.168.0.8]) ([72.30.28.113]) by smtp408.mail.bf1.yahoo.com (JAMES SMTP Server ) with ESMTPA ID e91bca0a42d00b26b35f602cab676006 for ; Tue, 16 Jan 2018 03:02:59 +0000 (UTC) To: FreeBSD Hackers From: Pedro Giffuni Subject: Re: examining Linux core file? Organization: FreeBSD Project Message-ID: Date: Mon, 15 Jan 2018 22:02:58 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2018 03:13:16 -0000 > On Sun, Jan 14, 2018 at 7:31 PM, Benjamin Kaduk wrote: > > On Sun, Jan 14, 2018 at 07:57:01AM -0800, Chuck Tuffli wrote: > >> If a Linux application running under the Linux emulation (a.k.a. > >> Linuxulator) core dumps, is it possible to examine the resulting core > >> file? lldb didn't seem to like it: > > > > I wonder how a Linux gdb running under the Linuxulator would fare > > with it? > > Sorry, that's what I was trying to show with the last example. The > Linux gdb from CentOS running under the Linuxulator gives: > > # gdb -q ./testcases/bin/mremap05 mremap05.core > Reading symbols from /opt/ltp/testcases/bin/mremap05...done. > > warning: A handler for the OS ABI "FreeBSD ELF" is not built into this > configuration > of GDB. Attempting to continue with the default i386:x86-64 settings. > > "/opt/ltp/mremap05.core": no core file handler recognizes format Weird, I think you would need to build a cross-gdb. My memory is sketchy but you may need to build a complete cross-toolchain for that. Long-long ago we actually did that but the resulting linux binaries were weird and needed branding always. Pedro. From owner-freebsd-hackers@freebsd.org Tue Jan 16 09:59:20 2018 Return-Path: Delivered-To: freebsd-hackers@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 DAD7BEB8FFF for ; Tue, 16 Jan 2018 09:59:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 71415712D2; Tue, 16 Jan 2018 09:59:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w0G9x9T9095277 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 16 Jan 2018 11:59:12 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w0G9x9T9095277 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w0G9x8Id095276; Tue, 16 Jan 2018 11:59:09 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 16 Jan 2018 11:59:08 +0200 From: Konstantin Belousov To: Pedro Giffuni Cc: FreeBSD Hackers Subject: Re: examining Linux core file? Message-ID: <20180116095908.GQ1684@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) 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 autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2018 09:59:20 -0000 On Mon, Jan 15, 2018 at 10:02:58PM -0500, Pedro Giffuni wrote: > > On Sun, Jan 14, 2018 at 7:31 PM, Benjamin Kaduk wrote: > > > On Sun, Jan 14, 2018 at 07:57:01AM -0800, Chuck Tuffli wrote: > > >> If a Linux application running under the Linux emulation (a.k.a. > > >> Linuxulator) core dumps, is it possible to examine the resulting core > > >> file? lldb didn't seem to like it: > > > > > > I wonder how a Linux gdb running under the Linuxulator would fare > > > with it? > > > > Sorry, that's what I was trying to show with the last example. The > > Linux gdb from CentOS running under the Linuxulator gives: > > > > # gdb -q ./testcases/bin/mremap05 mremap05.core > > Reading symbols from /opt/ltp/testcases/bin/mremap05...done. > > > > warning: A handler for the OS ABI "FreeBSD ELF" is not built into this > > configuration > > of GDB. Attempting to continue with the default i386:x86-64 settings. > > > > "/opt/ltp/mremap05.core": no core file handler recognizes format > > Weird, I think you would need to build a cross-gdb. > > My memory is sketchy but you may need to build a complete > cross-toolchain for that. Long-long ago we actually did that but the > resulting linux binaries were weird and needed branding always. No cross-toolchain will help there. Problem is that the binary is Linux, while core is FreeBSD. There are enough details significant to the debugger that make such combination a new platform. From owner-freebsd-hackers@freebsd.org Wed Jan 17 01:59:00 2018 Return-Path: Delivered-To: freebsd-hackers@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 762BDE71A94 for ; Wed, 17 Jan 2018 01:59:00 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [150.101.137.131]) by mx1.freebsd.org (Postfix) with ESMTP id F061C76E74 for ; Wed, 17 Jan 2018 01:58:59 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from 124-169-232-53.dyn.iinet.net.au (HELO midget.dons.net.au) ([124.169.232.53]) by ipmail07.adl2.internode.on.net with ESMTP; 17 Jan 2018 12:23:46 +1030 Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.15.1/8.14.9) with ESMTPS id w0H1rdhk091376 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 17 Jan 2018 12:23:39 +1030 (CST) (envelope-from darius@dons.net.au) Received: (from mailnull@localhost) by midget.dons.net.au (8.15.1/8.14.9/Submit) id w0H1US5l077491 for ; Wed, 17 Jan 2018 12:00:28 +1030 (CST) (envelope-from darius@dons.net.au) X-Authentication-Warning: midget.dons.net.au: mailnull set sender to using -f Received: from [10.176.138.114] (ns.dons.net.au [10.0.2.1]) by ns.dons.net.au (envelope-sender ) (MIMEDefang) with ESMTP id w0H1UMcu076565; Wed, 17 Jan 2018 12:00:28 +1030 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: examining Linux core file? From: "O'Connor, Daniel" In-Reply-To: <20180116095908.GQ1684@kib.kiev.ua> Date: Wed, 17 Jan 2018 12:00:22 +1030 Cc: Pedro Giffuni , FreeBSD Hackers Content-Transfer-Encoding: quoted-printable Message-Id: <32C3FADA-073C-4942-B12F-AEB7F345766E@dons.net.au> References: <20180116095908.GQ1684@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.3445.5.20) X-Spam-Score: -1 () No, score=-1.0 required=5.0 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable autolearn_force=no version=3.4.0 X-Scanned-By: MIMEDefang 2.75 on 10.0.2.1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jan 2018 01:59:00 -0000 > On 16 Jan 2018, at 20:29, Konstantin Belousov = wrote: >>=20 >> My memory is sketchy but you may need to build a complete=20 >> cross-toolchain for that. Long-long ago we actually did that but the=20= >> resulting linux binaries were weird and needed branding always. >=20 > No cross-toolchain will help there. Problem is that the binary is = Linux, > while core is FreeBSD. There are enough details significant to the = debugger > that make such combination a new platform. Using ktrace / linux_kdump might help - or at least give some clues as = to where it's failing too. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-hackers@freebsd.org Fri Jan 19 19:03:39 2018 Return-Path: Delivered-To: freebsd-hackers@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 1C227EC2566 for ; Fri, 19 Jan 2018 19:03:39 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id E8CD96FA95 for ; Fri, 19 Jan 2018 19:03:38 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from yv.noip.me (c-24-6-186-56.hsd1.ca.comcast.net [24.6.186.56]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id w0JJ3bvh044336 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 19 Jan 2018 11:03:37 -0800 (PST) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-24-6-186-56.hsd1.ca.comcast.net [24.6.186.56] claimed to be yv.noip.me To: Freebsd hackers list From: Yuri Subject: Does the kernel assign CPU affinity automatically? Message-ID: <38c78eec-b598-dc44-8422-ab8fdec0a735@rawbw.com> Date: Fri, 19 Jan 2018 11:03:35 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2018 19:03:39 -0000 I noticed that my particularly large process always runs on the same CPU through its lifetime (based on top). This process doesn't use cpuset(1) or cpuset(2), and cpuset(1) only shows the all-inclusive set: $ cpuset -g -p 11511 pid 11511 mask: 0, 1, 2, 3, 4, 5, 6, 7 Does the kernel assign CPU affinity automatically in some cases? There seems to be some factor besides 'cpuset' that determines affinity. Thanks, Yuri From owner-freebsd-hackers@freebsd.org Fri Jan 19 19:36:54 2018 Return-Path: Delivered-To: freebsd-hackers@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 F3BA2EC3B0B for ; Fri, 19 Jan 2018 19:36:53 +0000 (UTC) (envelope-from mizhka@gmail.com) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (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 77F9870FD0 for ; Fri, 19 Jan 2018 19:36:53 +0000 (UTC) (envelope-from mizhka@gmail.com) Received: by mail-lf0-x234.google.com with SMTP id t139so3396851lff.0 for ; Fri, 19 Jan 2018 11:36:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lyMgmcKEh9MLWtG81fXFFk+tx/U1MqzKNvp7V8LA3Ik=; b=AHhp8ZezpVoMHODNq42BxJDdO3ASjm9ywG7bgmqUc2JUHQrkW2eo7eG7kYFt6auaE3 TVln91YgruIqdL6cPRJOQyy5/se4lS4kIh4qAAvrKG1A8TM2YbOga5SrrwZSRzafKnWh 4d5qkHweUHdYvMZus2Bw2mb2aTQHo4zPtJ4SPNhuEPqUdJnryc13a7y3ajYCTzyvkB27 GymZ76oN87gy9f6/I9JOEUc2F3JMAxUmARBF2IFR8Qg7QEN2VS/7E4VFCNmEyc4k/dxd IXmgm6MCml4ymzgG+b23utfWNpw7d6A3F9wIqjAtSDAtQEcTcXeOpckopTBMZGltCcY7 uMyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lyMgmcKEh9MLWtG81fXFFk+tx/U1MqzKNvp7V8LA3Ik=; b=qpPhu7yMv/OSZgnrkjUDm+lwrS69DkxbJQB8Cx2pxeMb5VCHjir42q5INR2dUz6nj/ RcKWwr+yofRqMhVZ9do/+JHOMPOgYqWHKVCRCNhhjez98SXN2XAKY5+7bvwQ2G/zOu6e W7ecfmpb7bmvZVmmxAuorRKHWfp1G2Y6JIEX2oht6lWrW/BGpvIVePVEYyATxdWRPQO5 KFdO5TgfI5pzNO5/ywLn0G+zZdq5zRxNHh2MuX/SvUlngvuLIxfNOT//H6DFnL1JH/h7 cgyw3wT7qSUiaqsXr4Rtp5okRR5HzRkjOCxAoL8x+FIOhviv72GgyahU+FMb6KfSm6Z4 onKw== X-Gm-Message-State: AKwxytc5UNHBt9HeaqEf+GeqzAZshNgCoz0EnO2EuFG2wcYqbTNmppHh TDOgkeA5UJzT7g4knqG98ppGlQcLdlr6W/J7oC3bo9C0 X-Google-Smtp-Source: ACJfBovN6tOcCUyV6IkSActYKS8Ze3pU45MXSsz7LxnqllMfiXRxMAX781tbo1RGpPcwbeM84dgOFBXVYAt0H/mEdVg= X-Received: by 10.25.228.146 with SMTP id x18mr21937586lfi.115.1516390610665; Fri, 19 Jan 2018 11:36:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.101.91 with HTTP; Fri, 19 Jan 2018 11:36:50 -0800 (PST) In-Reply-To: <38c78eec-b598-dc44-8422-ab8fdec0a735@rawbw.com> References: <38c78eec-b598-dc44-8422-ab8fdec0a735@rawbw.com> From: Michael Zhilin Date: Fri, 19 Jan 2018 22:36:50 +0300 Message-ID: Subject: Re: Does the kernel assign CPU affinity automatically? To: Yuri Cc: Freebsd hackers list Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2018 19:36:54 -0000 Hi Yuri, May be just ULE? https://www.usenix.org/legacy/event/bsdcon03/tech/full_papers/roberson/roberson.pdf "The primary goal of ULE on SMP is to prevent unnecessary CPU migration while making good use of available CPU resources. The notion of trying to schedule threads onto the last CPU that they were run on is commonly called CPU affinity. It is important to balance the cost of migrating a CPU with the cost of leaving a CPU idle. " Best regards, Michael. On Fri, Jan 19, 2018 at 10:03 PM, Yuri wrote: > I noticed that my particularly large process always runs on the same CPU > through its lifetime (based on top). This process doesn't use cpuset(1) or > cpuset(2), and cpuset(1) only shows the all-inclusive set: > > $ cpuset -g -p 11511 > pid 11511 mask: 0, 1, 2, 3, 4, 5, 6, 7 > > Does the kernel assign CPU affinity automatically in some cases? There > seems to be some factor besides 'cpuset' that determines affinity. > > > > Thanks, > > Yuri > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Fri Jan 19 20:21:11 2018 Return-Path: Delivered-To: freebsd-hackers@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 35C90EC5B5B for ; Fri, 19 Jan 2018 20:21:11 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2478672D1F for ; Fri, 19 Jan 2018 20:21:10 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from yv.noip.me (c-24-6-186-56.hsd1.ca.comcast.net [24.6.186.56]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id w0JKL9Q5055188 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 19 Jan 2018 12:21:09 -0800 (PST) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-24-6-186-56.hsd1.ca.comcast.net [24.6.186.56] claimed to be yv.noip.me Subject: Re: Does the kernel assign CPU affinity automatically? To: Michael Zhilin Cc: Freebsd hackers list References: <38c78eec-b598-dc44-8422-ab8fdec0a735@rawbw.com> From: Yuri Message-ID: Date: Fri, 19 Jan 2018 12:21:06 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2018 20:21:11 -0000 On 01/19/18 11:36, Michael Zhilin wrote: > May be just ULE? > https://www.usenix.org/legacy/event/bsdcon03/tech/full_papers/roberson/roberson.pdf What motivated my question is that I don't see the same on other processes. For example, simple infinite cycle   for (;;) {} does switch CPUs. Yuri From owner-freebsd-hackers@freebsd.org Fri Jan 19 20:40:03 2018 Return-Path: Delivered-To: freebsd-hackers@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 842A8EC6F70 for ; Fri, 19 Jan 2018 20:40:03 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1366173FF7 for ; Fri, 19 Jan 2018 20:40:01 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w0JKdlrJ081730 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 19 Jan 2018 21:39:47 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: yuri@rawbw.com Received: from [10.58.0.4] (dadv@[10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w0JKdgOZ021487 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 20 Jan 2018 03:39:42 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Does the kernel assign CPU affinity automatically? To: Yuri , Freebsd hackers list References: <38c78eec-b598-dc44-8422-ab8fdec0a735@rawbw.com> From: Eugene Grosbein Message-ID: <5A625790.3010703@grosbein.net> Date: Sat, 20 Jan 2018 03:39:44 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <38c78eec-b598-dc44-8422-ab8fdec0a735@rawbw.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2018 20:40:03 -0000 20.01.2018 2:03, Yuri wrote: > I noticed that my particularly large process always runs on the same CPU through its lifetime (based on top). You should not trust your eyes looking at top(1) output because scheduler quantum is pretty short and a process can be switched many times per second between top's screen updates. Instead, you should use sysctl kern.cp_times providing detailed ever incrementing counters for per-core idle/kernel/interrupt/nice/normal ticks (ticks have 1/stathz frequency, see sysctl kern.clockrate) to draw graphs or make comparisons. They allow you to check if such heavy process makes even load on every CPU core or not. From owner-freebsd-hackers@freebsd.org Sat Jan 20 23:27:37 2018 Return-Path: Delivered-To: freebsd-hackers@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 26833ECD2CD for ; Sat, 20 Jan 2018 23:27:37 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic302-4.consmr.mail.bf2.yahoo.com (sonic302-4.consmr.mail.bf2.yahoo.com [74.6.135.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E3DEE6FD8D for ; Sat, 20 Jan 2018 23:27:36 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: RU4jjAIVM1kwHHpPaWj5mI469eeKAaxVMj2AY52F0cJm3BjJVb8hrE6Qsdg5aXD TVPC4j40C_tMAGYVa9E3730IGmz4_Uuch4HzpYBZheJrrWXWcTZZldkI.8kxJ2Xv0OzGf3Mx7C2Z XNVSHxoBV6oshOzyFU3a.4L_SM9rxM5G8R2WFlXpc5lKEK9etUsc_MWr05SSvs_ea1bkh_obSdmv iZXEfaSCIWvDYtXzO7y19vebuqzGfmQy2QcybTOnBlt4z19dfTS8VCbPKZ8MYXvIXZTAxLcUHUJP FQ_k6hPjdFaJ0RNmp9VokEQkJ1ysF6iPHSeXJb4Utd_XUZ1JUjEY4bgEOwT4GyofC1HJVXgthdyl ci86dWWiZCLGX5LD6CV9KtMniV_8BT5vLXK9h7hNLcEs79c4lEP3ie.T7_Zp75JIpx6z7oYlu1_C D09FZbkgOmR8LWKBopsNLBKT5yy3BK46MYtcbSZuBKXFNgNzKHMPIG4qYf1Ly4fj5Mzh2 Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Sat, 20 Jan 2018 23:27:30 +0000 Received: from smtp106.rhel.mail.bf1.yahoo.com (EHLO [192.168.1.25]) ([98.139.231.40]) by smtp404.mail.bf1.yahoo.com (JAMES SMTP Server ) with ESMTPA ID 26a397299a489e18397ec8a26c8a640a; Sat, 20 Jan 2018 23:27:25 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Attribute alloc__size use and clang 5.0.1 vs. gcc7 (e.g.): __builtin_object_size(p,1) and __builtin_object_size(p,3) disagreements result Message-Id: <1AA0993D-81E4-4DC0-BBD9-CC42B26ADB1C@yahoo.com> Date: Sat, 20 Jan 2018 15:27:23 -0800 To: Pedro Giffuni , FreeBSD Toolchain , FreeBSD Hackers X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2018 23:27:37 -0000 [Bugzilla 225197 indirectly lead to this. Avoiding continuing there.] I decided to compare some alternate uses of __attribute__((alloc_size(. . .))) compiled and run under clang 5.0.1 and gcc7. I did not get what I expected based on prior discussion material. This is an FYI since I do not know how important the distinctions that I found are. Here is the quick program: # more alloc_size_attr_test.c=20 #include #include __attribute__((alloc_size(1,2))) void* my_calloc_alt0(size_t n, size_t s) { void* p =3D calloc(n,s); printf("calloc __builtin_object_size 0,1,2,3: %ld, %ld, %ld, %ld\n" ,(long) __builtin_object_size(p, 0) ,(long) __builtin_object_size(p, 1) ,(long) __builtin_object_size(p, 2) ,(long) __builtin_object_size(p, 3) ); return p; } __attribute__((alloc_size(1))) __attribute__((alloc_size(2))) void* my_calloc_alt1(size_t n, size_t s) { void* p =3D calloc(n,s); printf("calloc __builtin_object_size 0,1,2,3: %ld, %ld, %ld, %ld\n" ,(long) __builtin_object_size(p, 0) ,(long) __builtin_object_size(p, 1) ,(long) __builtin_object_size(p, 2) ,(long) __builtin_object_size(p, 3) ); return p; } int main() { void* p =3D my_calloc_alt0(2,7); printf("my_calloc_alt0 __builtin_object_size 0,1,2,3: %ld, %ld, %ld, = %ld\n" ,(long) __builtin_object_size(p, 0) ,(long) __builtin_object_size(p, 1) ,(long) __builtin_object_size(p, 2) ,(long) __builtin_object_size(p, 3) ); void* q =3D my_calloc_alt1(2,7); printf("my_calloc_alt0 __builtin_object_size 0,1,2,3: %ld, %ld, %ld, = %ld\n" ,(long) __builtin_object_size(q, 0) ,(long) __builtin_object_size(q, 1) ,(long) __builtin_object_size(q, 2) ,(long) __builtin_object_size(q, 3) ); } # uname -apKU FreeBSD FBSDFSSD 12.0-CURRENT FreeBSD 12.0-CURRENT r327485M amd64 = amd64 1200054 1200054 The system-clang 5.0.1 result was: # clang -O2 alloc_size_attr_test.c # ./a.out calloc __builtin_object_size 0,1,2,3: 14, 14, 14, 0 my_calloc_alt0 __builtin_object_size 0,1,2,3: 14, 14, 14, 0 calloc __builtin_object_size 0,1,2,3: 14, 14, 14, 0 my_calloc_alt0 __builtin_object_size 0,1,2,3: 14, 14, 14, 0 The lang/gcc7 result was: # gcc7 -O2 alloc_size_attr_test.c # ./a.out calloc __builtin_object_size 0,1,2,3: -1, -1, 0, 0 my_calloc_alt0 __builtin_object_size 0,1,2,3: 14, 14, 14, 14 calloc __builtin_object_size 0,1,2,3: -1, -1, 0, 0 my_calloc_alt0 __builtin_object_size 0,1,2,3: 14, 7, 14, 14 I'll ignore that gcc does not provide actual sizes via __builtin_object_size for calloc use. Pairing the other lines for easy comparison, with some notes mixed in: __attribute__((alloc_size(1,2))) style: my_calloc_alt0 __builtin_object_size 0,1,2,3: 14, 14, 14, 0 (system = clang) my_calloc_alt0 __builtin_object_size 0,1,2,3: 14, 14, 14, 14 (gcc7) __attribute__((alloc_size(1))) __attribute__((alloc_size(2))) style: my_calloc_alt0 __builtin_object_size 0,1,2,3: 14, 14, 14, 0 (system = clang) my_calloc_alt0 __builtin_object_size 0,1,2,3: 14, 7, 14, 14 (gcc7) Thus. . . For __attribute__((alloc_size(1))) __attribute__((alloc_size(2))): __builtin_object_size(p,1) is not equivalent (clang vs. gcc7) For both of the alloc_size usage styles: __builtin_object_size(p,3) is not equivalent (clang vs. gcc7) This means that the two style of alloc_size use are not equivalent across some major compilers/toolchains. But I do not know if either of the differences is a problem or not. Note: without a sufficient -O all the figures can be the mix of -1's and 0's. =3D=3D=3D Mark Millard marklmi at yahoo.com ( markmi at dsl-only.net is going away in 2018-Feb, late)