Message ID | 59EF4D34.4020506@arm.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 116057 invoked by alias); 24 Oct 2017 14:25:00 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <libc-alpha.sourceware.org> List-Unsubscribe: <mailto:libc-alpha-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 116014 invoked by uid 89); 24 Oct 2017 14:24:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-24.8 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-spam-relays-external:sk:EUR02-A, HX-HELO:sk:EUR02-A, H*RU:sk:EUR02-A X-HELO: EUR02-AM5-obe.outbound.protection.outlook.com Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Szabolcs.Nagy@arm.com; Message-ID: <59EF4D34.4020506@arm.com> Date: Tue, 24 Oct 2017 15:24:52 +0100 From: Szabolcs Nagy <szabolcs.nagy@arm.com> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: GNU C Library <libc-alpha@sourceware.org> CC: nd@arm.com Subject: [PATCH 1/7] Mark lazy tlsdesc helper functions unused to avoid warnings References: <59EF4CEC.8020301@arm.com> In-Reply-To: <59EF4CEC.8020301@arm.com> Content-Type: multipart/mixed; boundary="------------020202080601000506060101" X-ClientProxiedBy: LO2P265CA0070.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:60::34) To AM5PR0802MB2482.eurprd08.prod.outlook.com (2603:10a6:203:98::23) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 3756fbc4-1b1c-4b5c-9e46-08d51aeafea3 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199)(49563074); SRVR:AM5PR0802MB2482; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0802MB2482; 3:fAAHh4x6nDhrI4jgKX4vyPLDQbILdyDPizMN9n51MxJw2Dqt6FGrRpI0jj2NfofwYkcpjAcroyAfpTrQrOs+crsFDLFrXEWYlKt5gxypqX7V/q3IVYbS/286N5LvN9o+/pU9w4CJkddYtDvH8fgwizr/MMIktoAZ8z+7lj9U8ccTL1nxL6GylSEcsSXcwmupYcHV+Yc66pW5FP1kY1Av5tROJiqVjm5TIxYZVvqVebSHCGQAU4vRgK+bEcDJGn+w; 25:7rzx6iy13zYJZHz2u32di9qyMw5332rJ1YTW8+Jggx8rBDzadMDrhQaBLGK3p8gnVk7I7JP+FznDK6V7C07UuXzxf0g6aB1KROjF95S3YuyWDcvxmpAR7Svoow/3i4RXu4qwQDsEDrH25+nQFmA2lNqdqRSKzOFhXMNzlMq4oxiivhNP3jjGF/vXHiMW7lHJzUhIiUXHJ+mwBmTIKU1ivVl2J2+ADcijegDTiOuLgOI=; 31:/4traot4iz+xEQYURvVUcJs5wSZssSY0zxpKHZAw5EVr9hl6rU4TVBaRCvj+IVxS7BSUPG/DlKBUWSUfpGdXGFzyt47gmJnxy1Ulcbl2Uwrj5G7/hRFhIneZVFQBoR0r; 20:h8thuakp4+j4VxhlZsfPwchAzLll+1BjrzvDjW5n7MNjRVOsM1l/oxmg36/LjWzLpqpcVXQ1RpHFIUt7TN6ivv/Y2O1SrRuX7FKNlQYMQJoBsjuwnMGiRMoFw8IZZWJ7455gCu/4h7NPtSUtrIHMLGohX6Sa++mJZfcwGVTCxGE= X-MS-TrafficTypeDiagnostic: AM5PR0802MB2482: NoDisclaimer: True X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: <AM5PR0802MB2482A1B2790410FE690DE2B0ED470@AM5PR0802MB2482.eurprd08.prod.outlook.com> X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3231020)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0802MB2482; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0802MB2482; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0802MB2482; 4:fyJWREYxHw9gHYgdZ5tEiaV8l2yozq2pJAfKwMNZ53jwKeRIstMEiSw/fYLjXDgbWTxD0G5SMdKzvIHkCuXH/JfIQqcYmgLTAjIQUSdJUzlpn0PfBx6VX9e6x3c1PV00xmI077dGcHsbm6eE9P+oWw== X-Forefront-PRVS: 047001DADA X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(6009001)(346002)(376002)(39860400002)(199003)(189002)(81166006)(6916009)(68736007)(6116002)(36756003)(6486002)(77096006)(65816999)(53936002)(87266999)(16586007)(316002)(16576012)(54356999)(76176999)(58126008)(101416001)(105586002)(50986999)(33656002)(2906002)(305945005)(59896002)(564344004)(83506002)(562524006)(270700001)(2476003)(568964002)(4326008)(106356001)(3846002)(65956001)(16526018)(4610100001)(5000100001)(72206003)(478600001)(5890100001)(7736002)(8936002)(2950100002)(66066001)(25786009)(65806001)(573454002)(86362001)(97736004)(84326002)(80316001)(81156014)(64126003)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0802MB2482; H:[10.2.206.69]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; AM5PR0802MB2482; 23:aYEaZ8UjQyYAAg1XYpZ6Md4rJNwN9Ta75VQaeex?= =?us-ascii?Q?dXhrU4TivGSGZriPg5LMkV29nAJttrtd+10pkwCP7V27bT1XSFV7jh+rEH6T?= =?us-ascii?Q?9UAFhd0d02t+YUP4/ENZuqPfltyNXpCR24L6j+XS4WyeU4TndXMug8PAlbXG?= =?us-ascii?Q?Oy6n8Ot8KpAnaIY7GcAkEa3lQc1GN/XBcxQX+H5qko+hXIN8zCWB+9uiij1M?= =?us-ascii?Q?iIlCAZM84durc0TdVvMaF0YMnm7JkIdj6XvDZFIHao0W2ai3iW5626OskmRN?= =?us-ascii?Q?9i8tI8ZQyITkrGvoos0Q+Do6kJ1GwNxtAKkS7Xq6aAtKD7fVWijyQwuEdrc7?= =?us-ascii?Q?eSRDdKqcA16CclXZBtW997a0lx49abopWVps4hgEZq4N2NBz2lSMOwe6jq7c?= =?us-ascii?Q?iQM+yWPs9AvsTqWXv8cT00Kn43xptaBSXQAt6gtSRDZ97cZ8PCaVfof8JjY6?= =?us-ascii?Q?0w3ph9aNmwo5A5KfGYofdFJT7aSaC8Ktwjjf0w1Sa6dL1p6GOtaam5mPqk6U?= =?us-ascii?Q?olWYkGJ8uMu+UTbg0GCtXgsyX6Py7hnyeY9RjXVTTSvJZk+x87pfLrk88dkQ?= =?us-ascii?Q?tQszDbqHoNtshgeFJ1FjzWCESUSfC0XDA4l9n9xSbV+hMrlGcx6tDHnqU+7Y?= =?us-ascii?Q?DLnv0agEsH4xYC0Tgsvlk6TFC0q06rDguLNGWeizXKBbt22A03bHOHxKrE01?= =?us-ascii?Q?1r5JGN6biOP1Mao7OXcALR+MHrlXnUoRERgNJ9y5iPYUWcAEB03T6n3qxUap?= =?us-ascii?Q?+oIixMGcAh27AXalkEwEG6ele34Vbk5yqqXUAIMXDzKAUzpXqO9TR4m+cCSu?= =?us-ascii?Q?FH3CMm+/IcM7R9R+aV9wJZt4EoIYpmQs2rc+y7bL8qiwpAwTZGWJbPbBJgGp?= =?us-ascii?Q?2aCSacobcb9MCgopw6VOxNC+49bP933HiLBTo/NzCkGnHTHlVeyKWWQkEwML?= =?us-ascii?Q?Zx2z6xha8qTkXnSGeZGqU5yNNedJcmkRuKzDbxxh5jm1YEawbxXiOJq01o7y?= =?us-ascii?Q?gkShW1CmAN1Iy/GHDuiUvr84TvwY1vWPoOLxugC3vjFBqN+syXiPSt3JPHFT?= =?us-ascii?Q?sEwc69rF4Xgfb9u/Hjl9DB436HiZkr5nsrWMRVAvyUyyMVOwrkmXJDE3BNKu?= =?us-ascii?Q?rnVs/JMuA4xGP0KIdmcQxRZBZBEfR+v/Xgw0hAkYweKBWVLTl1Uek88IGDJD?= =?us-ascii?Q?SOxqP/Vh0aQa2LtjgicVv2Pak2ZtKC+HDFNEhKl5eDka94jrVvB7iItSD+q7?= =?us-ascii?Q?kC7zWYum0yvba+7+9NVoq/BLtQPyl8BlPjrLiR5rQrhyvmg7YZlHBW63T3aQ?= =?us-ascii?Q?vVAGSl24oyS1U9ZgdUWSOuoJkC/SfFtBrqZagq+8VyOdFMNQtf1NhHIcaR+G?= =?us-ascii?Q?FmpN5QNJfhcZDFezJKaOKrgCU4LaV2cQlDt8fEWbPDgfcUsc+?= X-Microsoft-Exchange-Diagnostics: 1; AM5PR0802MB2482; 6:DaC+wLsZcUZ6fdJ/lnFqrUC3nJ3PZe4oVRIW9ErS6DRlHLqA5oxmoyorc3WgyBCN9fPylEvFMSREhk7MAE0YSAkIAEktL2NU1S3gYFvhi4VTg32na2llpJGgMUhFry1HFu9CpN/k9qrDUUp0ZdXYyFq1qDN/QXpmGh3MmREv3Dc9RBA04ejTF4+NrkxHDYPPVghUy88xZVSEDqtWzQMtqa7bAkzqQcBi6NLCIEcBFXg=; 5:kLQeJo5mHDtV4VhM++iIakZ7KFN6y/TKhvqekSgUqTv/ojhHAiaENlknLuWrYzRg0czeoEEIpkV7xEscONanUbFIz91yra+02/mgp7wYu7ek6otu6Srn1o2xZ8ZgpnnFptXVEEhuvz+6BS9fb0ec8w==; 24:LB8808LMtzxIMMTkTS4gg7Te1HeZjPX0D0zbCiZENTKETqAnfTWkzYYZIvDw+REEbUwi2gA/XFZlNXPzdqTg7eumEDeIPeiLdLCC4CvNvH0=; 7:IX75B79j7wD6rfhMWUtOYsnV91x4iazzL8DnRMegqmSzxICY2BvkSyhJ4jFPK1tXf0/iWZ+ftC2W4quQc7t6iCaT6wVqeXm3YCiHV07FYHErbNnSljkU4apCBM7YE/XA+sVnmvV0Ytk0vCGLqzvE9JOLjbM4LEAw3N+NXDYPT5pKNabtXHgypVxpkeI9A6MU5JSzkidImddav4wS+1JChEiZA4C2hsQr0r19cdou9Z0= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Oct 2017 14:24:53.8660 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3756fbc4-1b1c-4b5c-9e46-08d51aeafea3 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0802MB2482 |
Commit Message
Szabolcs Nagy
Oct. 24, 2017, 2:24 p.m. UTC
Comments
On 24/10/17 15:24, Szabolcs Nagy wrote: > From 74f8c71fee285657860926c8e45227041265d15d Mon Sep 17 00:00:00 2001 > From: Szabolcs Nagy <szabolcs.nagy@arm.com> > Date: Mon, 23 Oct 2017 12:15:40 +0100 > Subject: [PATCH 1/7] Mark lazy tlsdesc helper functions unused to avoid > warnings > > These static functions are not needed if a target does not do lazy > tlsdesc initialization. > > 2017-10-23 Szabolcs Nagy <szabolcs.nagy@arm.com> > > * elf/tlsdeschtab.h (_dl_tls_resolve_early_return_p): Mark unused. > (_dl_tlsdesc_wake_up_held_fixups): Likewise. i'd like to get consensus on this (trivial) change. once it's committed, other targets (i386, x86_64) can also remove lazy tlsdesc code. after that these functions can be completely removed. > --- > elf/tlsdeschtab.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/elf/tlsdeschtab.h b/elf/tlsdeschtab.h > index ad3001dac5..879631897c 100644 > --- a/elf/tlsdeschtab.h > +++ b/elf/tlsdeschtab.h > @@ -137,6 +137,7 @@ _dl_make_tlsdesc_dynamic (struct link_map *map, size_t ti_offset) > avoid introducing such dependencies. */ > > static int > +__attribute__ ((unused)) > _dl_tlsdesc_resolve_early_return_p (struct tlsdesc volatile *td, void *caller) > { > if (caller != atomic_load_relaxed (&td->entry)) > @@ -155,6 +156,7 @@ _dl_tlsdesc_resolve_early_return_p (struct tlsdesc volatile *td, void *caller) > } > > static void > +__attribute__ ((unused)) > _dl_tlsdesc_wake_up_held_fixups (void) > { > __rtld_lock_unlock_recursive (GL(dl_load_lock)); > -- 2.11.0 >
On 27/10/17 15:20, Szabolcs Nagy wrote: > On 24/10/17 15:24, Szabolcs Nagy wrote: >> From 74f8c71fee285657860926c8e45227041265d15d Mon Sep 17 00:00:00 2001 >> From: Szabolcs Nagy <szabolcs.nagy@arm.com> >> Date: Mon, 23 Oct 2017 12:15:40 +0100 >> Subject: [PATCH 1/7] Mark lazy tlsdesc helper functions unused to avoid >> warnings >> >> These static functions are not needed if a target does not do lazy >> tlsdesc initialization. >> >> 2017-10-23 Szabolcs Nagy <szabolcs.nagy@arm.com> >> >> * elf/tlsdeschtab.h (_dl_tls_resolve_early_return_p): Mark unused. >> (_dl_tlsdesc_wake_up_held_fixups): Likewise. > > i'd like to get consensus on this (trivial) change. > any comments on this? > once it's committed, other targets (i386, x86_64) can > also remove lazy tlsdesc code. > > after that these functions can be completely removed. > >> --- >> elf/tlsdeschtab.h | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/elf/tlsdeschtab.h b/elf/tlsdeschtab.h >> index ad3001dac5..879631897c 100644 >> --- a/elf/tlsdeschtab.h >> +++ b/elf/tlsdeschtab.h >> @@ -137,6 +137,7 @@ _dl_make_tlsdesc_dynamic (struct link_map *map, size_t ti_offset) >> avoid introducing such dependencies. */ >> >> static int >> +__attribute__ ((unused)) >> _dl_tlsdesc_resolve_early_return_p (struct tlsdesc volatile *td, void *caller) >> { >> if (caller != atomic_load_relaxed (&td->entry)) >> @@ -155,6 +156,7 @@ _dl_tlsdesc_resolve_early_return_p (struct tlsdesc volatile *td, void *caller) >> } >> >> static void >> +__attribute__ ((unused)) >> _dl_tlsdesc_wake_up_held_fixups (void) >> { >> __rtld_lock_unlock_recursive (GL(dl_load_lock)); >> -- 2.11.0 >> >
On 10/24/2017 04:24 PM, Szabolcs Nagy wrote: > diff --git a/elf/tlsdeschtab.h b/elf/tlsdeschtab.h > index ad3001dac5..879631897c 100644 > --- a/elf/tlsdeschtab.h > +++ b/elf/tlsdeschtab.h > @@ -137,6 +137,7 @@ _dl_make_tlsdesc_dynamic (struct link_map *map, size_t ti_offset) > avoid introducing such dependencies. */ > > static int > +__attribute__ ((unused)) > _dl_tlsdesc_resolve_early_return_p (struct tlsdesc volatile *td, void *caller) > { > if (caller != atomic_load_relaxed (&td->entry)) > @@ -155,6 +156,7 @@ _dl_tlsdesc_resolve_early_return_p (struct tlsdesc volatile *td, void *caller) > } > > static void > +__attribute__ ((unused)) > _dl_tlsdesc_wake_up_held_fixups (void) > { > __rtld_lock_unlock_recursive (GL(dl_load_lock)); I think the preferred syntax is to put the attribute before the return type; after the type, it would apply to the type, and not the function, and GCC has hacks to support that, but that will only work for some types. Otherwise, this looks okay to me. Thanks, Florian
On 03/11/17 12:14, Florian Weimer wrote: > On 10/24/2017 04:24 PM, Szabolcs Nagy wrote: >> diff --git a/elf/tlsdeschtab.h b/elf/tlsdeschtab.h >> index ad3001dac5..879631897c 100644 >> --- a/elf/tlsdeschtab.h >> +++ b/elf/tlsdeschtab.h >> @@ -137,6 +137,7 @@ _dl_make_tlsdesc_dynamic (struct link_map *map, size_t ti_offset) >> avoid introducing such dependencies. */ >> static int >> +__attribute__ ((unused)) >> _dl_tlsdesc_resolve_early_return_p (struct tlsdesc volatile *td, void *caller) >> { >> if (caller != atomic_load_relaxed (&td->entry)) >> @@ -155,6 +156,7 @@ _dl_tlsdesc_resolve_early_return_p (struct tlsdesc volatile *td, void *caller) >> } >> static void >> +__attribute__ ((unused)) >> _dl_tlsdesc_wake_up_held_fixups (void) >> { >> __rtld_lock_unlock_recursive (GL(dl_load_lock)); > > I think the preferred syntax is to put the attribute before the return type; after the type, it would apply to > the type, and not the function, and GCC has hacks to support that, but that will only work for some types. > hm.. current uses of unused attribute for the same purpose come after the return type: crypt/crypt_util.c nptl/pthread_cond_common.c stdio-common/_itowa.h nis/nss-nisplus.h sysdeps/unix/sysv/linux/dl-librecon.h sysdeps/unix/sysv/linux/exit-thread.h sysdeps/unix/sysv/linux/sigset-cvt-mask.h sysdeps/*/dl-procinfo.h sysdeps/*/dl-machine.h sysdeps/unix/sysv/linux/*/dl-procinfo.h iconv/gconv_charset.h locale/elem-hash.h locale/programs/locfile.h nscd/nscd-client.h posix/regex_internal.h elf/get-dynamic-info.h in fact the only cases where i see different order is your code in: resolv/resolv_context.h malloc/dynarray-skeleton.c (and even these two files use inconsistent ordering) > Otherwise, this looks okay to me. > > Thanks, > Florian
On 11/03/2017 01:41 PM, Szabolcs Nagy wrote: >> I think the preferred syntax is to put the attribute before the return type; after the type, it would apply to >> the type, and not the function, and GCC has hacks to support that, but that will only work for some types. >> > hm.. current uses of unused attribute for the > same purpose come after the return type: I meant the preferred syntax on the GCC side. But it was just a suggestion. For the unused attribute, the distinction truly does not matter. Thanks, Florian
On 03/11/17 14:28, Florian Weimer wrote: > On 11/03/2017 01:41 PM, Szabolcs Nagy wrote: >>> I think the preferred syntax is to put the attribute before the return type; after the type, it would apply to >>> the type, and not the function, and GCC has hacks to support that, but that will only work for some types. >>> >> hm.. current uses of unused attribute for the >> same purpose come after the return type: > > I meant the preferred syntax on the GCC side. But it was just a suggestion. For the unused attribute, the > distinction truly does not matter. > i see. i committed the patch as is, we can fix the order later together with other attributes. (although the plan is to drop this code eventually)
From 74f8c71fee285657860926c8e45227041265d15d Mon Sep 17 00:00:00 2001 From: Szabolcs Nagy <szabolcs.nagy@arm.com> Date: Mon, 23 Oct 2017 12:15:40 +0100 Subject: [PATCH 1/7] Mark lazy tlsdesc helper functions unused to avoid warnings These static functions are not needed if a target does not do lazy tlsdesc initialization. 2017-10-23 Szabolcs Nagy <szabolcs.nagy@arm.com> * elf/tlsdeschtab.h (_dl_tls_resolve_early_return_p): Mark unused. (_dl_tlsdesc_wake_up_held_fixups): Likewise. --- elf/tlsdeschtab.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/elf/tlsdeschtab.h b/elf/tlsdeschtab.h index ad3001dac5..879631897c 100644 --- a/elf/tlsdeschtab.h +++ b/elf/tlsdeschtab.h @@ -137,6 +137,7 @@ _dl_make_tlsdesc_dynamic (struct link_map *map, size_t ti_offset) avoid introducing such dependencies. */ static int +__attribute__ ((unused)) _dl_tlsdesc_resolve_early_return_p (struct tlsdesc volatile *td, void *caller) { if (caller != atomic_load_relaxed (&td->entry)) @@ -155,6 +156,7 @@ _dl_tlsdesc_resolve_early_return_p (struct tlsdesc volatile *td, void *caller) } static void +__attribute__ ((unused)) _dl_tlsdesc_wake_up_held_fixups (void) { __rtld_lock_unlock_recursive (GL(dl_load_lock)); -- 2.11.0