From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-3.7 required=3.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id A54981F601 for ; Fri, 2 Dec 2022 16:38:40 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=clisp.org header.i=@clisp.org header.b="O+Q73+Lc"; dkim-atps=neutral Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p193Q-0004ib-2r; Fri, 02 Dec 2022 11:38:24 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p193O-0004iA-3t for bug-gnulib@gnu.org; Fri, 02 Dec 2022 11:38:22 -0500 Received: from mo4-p00-ob.smtp.rzone.de ([81.169.146.161]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p193L-00012f-MB for bug-gnulib@gnu.org; Fri, 02 Dec 2022 11:38:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1669999092; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=2AgPI/GNQDnCsoeg6CdfYW2wnxzaHhRh6Sy4q4FrqIY=; b=O+Q73+LcsZ3D8pfePISpgolI6oczXS+FffXYzOy3iB9IkFBkJK3JEkmNUO7X48/k3S F3hJkoaK1pdRetYqQjXyWQ7XnJdYqP/ygDCmwLKzdxPNKI9583eP7xOZmLxghQ2k/9lJ VWsF3hIyyQSv3ojloPugU6z1BvVEDhIAPaNdo5oTc8uVUP/DCYH12LPfttsYGxfu1Wq2 mlcMbMbZ+YO7cThw0K9Z2vXVcFfxxxWq0HxwnrRqLd5pdN+I9muoze1Vd5ik5n/LfIxe THqVClBUB9Ami6XLC57SWyt0fT7o2qg5/2WqHVBqMNhFnb93xyZ1TYkkD1vSknRWDyoM dnow== Authentication-Results: strato.com; dkim=none X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH0WWb0LN8XZoH94zq68+3cfpPCiKBCKp9LKWRxD9uOrnBPf5Yw" X-RZG-CLASS-ID: mo00 Received: from nimes.localnet by smtp.strato.de (RZmta 48.2.1 AUTH) with ESMTPSA id v9c7e6yB2GcCTsu (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Fri, 2 Dec 2022 17:38:12 +0100 (CET) From: Bruno Haible To: bug-gnulib@gnu.org Cc: Florian Weimer Subject: Re: Hidden visibility for obstack symbols Date: Fri, 02 Dec 2022 17:38:12 +0100 Message-ID: <2223545.o7ts2hSHzF@nimes> In-Reply-To: <87pmd1rfkw.fsf@oldenburg.str.redhat.com> References: <87pmd1rfkw.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Received-SPF: none client-ip=81.169.146.161; envelope-from=bruno@clisp.org; helo=mo4-p00-ob.smtp.rzone.de X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org =46lorian Weimer wrote: > Someone reported that ls in coreutils exported _obstack* symbols. This > is because ls uses the obstack module from gnulib (I assume). Due to > the way ELF linking works by default, this promotes the symbols to > global visibility, so that there is a single definition in the entire > process. This is always a bit iffy (glibc supports it explicitly for > malloc-related symbols, though), but in case of obstack it's really not > great because the gnulib ABI is different from the glibc ABI: >=20 > $ gdb /usr/bin/ls > [=E2=80=A6] > (gdb) ptype _obstack_begin > type =3D int (struct obstack *, size_t, size_t, void *(*)(size_t),=20 > void (*)(void *)) > $ gdb /lib64/libc.so.6 > [=E2=80=A6] > (gdb) ptype _obstack_begin > type =3D int (struct obstack *, int, int, void *(*)(long),=20 > void (*)(void *)) >=20 > This is on x86-64, so the types aren't equivalent. >=20 > Would it be possible to give the obstack symbols hidden visibility? I would suggest to do something about it *only* if it is an actual problem. I claim that it is not an actual problem: $ nm --dynamic /bin/ls | grep -v ' U ' w __cxa_finalize@GLIBC_2.2.5 w __gmon_start__ w _ITM_deregisterTMCloneTable w _ITM_registerTMCloneTable 00000000000106e0 T _obstack_allocated_p 00000000000220a0 D obstack_alloc_failed_handler 000000000000fc80 T _obstack_begin 000000000000fca0 T _obstack_begin_1 0000000000010720 T _obstack_free 00000000000107b0 T _obstack_memory_used 000000000000fcc0 T _obstack_newchunk Among these symbols: * _obstack_allocated_p is irrelevant, since it is only present for debuggin= g, not even declared in . The remaining symbols are (with prototypes and parameter names): extern void _obstack_newchunk (struct obstack *, int length); extern int _obstack_begin (struct obstack *, int size, int alignment, void *(*)(long size), void (*)(void *)); extern int _obstack_begin_1 (struct obstack *, int size, int alignment, void *(*)(void *, long size), void (*)(void *, void *), void *); extern int _obstack_memory_used (struct obstack *) __attribute_pure__; extern void _obstack_free (struct obstack *, void *); extern void (*obstack_alloc_failed_handler) (void); =46or arguments of type 'int' and with names 'length', 'size', 'alignment', the valid values are in the range 0..INT_MAX. Similarly, the return value of _obstack_memory_used must be in the range 0..INT_MAX. =46or 32-bit platforms, such arguments are passed in the same location, whether it's declared as 'int' or 'size_t'. Likewise for a return value. =46or 64-bit platforms: * On the Linux platforms with CPU aarch64, powerpc64, s390x, x86_64, 32-bit values are passed in a 64-bit register. Whether sign-extended or zero-extended, does not matter, since the value is in the range 0..INT_MAX. * On the Linux platforms with CPU alpha, ia64, loongarch64, mips64, riscv64, sparc64, 32-bit values are passed as a 64-bit value in the stack argument sequence (part of which can be mapped to registers). Again, whether it's sign-extended or zero-extended, does not matter, since the value is in the range 0..INT_MAX. =46inally, there are the ABIs mips-n32 and x86_64-x32. Here, 32-bit values are passed as 32-bit, and 64-bit values as 64-bit. So, for these ABIs there would be a problem. But there are no distros that use these ABIs for the coreutils package. - Porting to x86_64-x32 essentially stopped in 2012; there have already been discussions whether to deprecate this ABI. [1] - For mips-n32, I can see that distros prefer to ship mips-32 binaries. For example: $ file /bin/ls /bin/ls: ELF 32-bit LSB executable, MIPS, MIPS-II version 1 (SYSV), d= ynamically linked, interpreter /lib/ld.so.1, for GNU/Linux 2.6.32, BuildID[= sha1]=3D7f52495c14dbba5d1918cb3450fcc47a44f275bd, stripped If it was an n32 binary, this output would show /lib32/ld.so.1, not /li= b/ld.so.1. Bruno [1] https://en.wikipedia.org/wiki/X32_ABI