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: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (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 5807D1F619 for ; Tue, 25 Feb 2020 14:36:59 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version:content-type; q=dns; s=default; b=oRjKQ fYH0adl4tCi5iXIT41u4NfhG3ieBJDb6+eFI1oQdhnftZWI1zQuSp6zzD1OG4CAB uND9F9rN+hjJpSV/snsp0J3w+chU4WjzRJMNFgf9t8ZE9u0cDY0Kwc7/R/CP2p5D LDyNTxs8o9Zcfde0SWU9HNHzgWiju+mZb8wDAc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version:content-type; s=default; bh=L9bgZlSKmrI UdBR5CUN6ozJ06RU=; b=UegOLc9gYwXj4kAj3x3fSmpi1ujKOsNbnqINsu/aMna NfCzRhQKgeB8s9YHNPPYeNVV+de80IZkOY0xzh0+TiYqPlenf3KbCtzwq9jYVo80 VcDE+X2tUgK6KP06F8yC4XJ3KXrjflT9sbmJSlKKs5LSSJyoaDZJgUI8yATn4V9U = Received: (qmail 126282 invoked by alias); 25 Feb 2020 14:36:57 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 126274 invoked by uid 89); 25 Feb 2020 14:36:57 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: esa2.mentor.iphmx.com IronPort-SDR: mvOzs6MTLE+KKOtmUyZn9ve61WgerK7a2BFRTMeBA2+taNlsvbt2S8S3HgqlT/IibZp0fNz9np cNE7qr5xBKahxJ2aGhRmar9kCt/iR9wHo+uwuIeimoSEd7cZ1lZ6R+4N67HWZJWPyfGWt+4Yw5 PpYzPjBZFiL5V+rtufiLjEIKBGACV0rfVLy+dEIA3u5qFySXSenIVwo4PyvNQyaoAF4vsHHARX XIM1its355z/0McVD8mf9+NM9d87rqlPERLT+ZVrl6YnRR7kLaUVrcoH3GXT9v2RcRW1FAUPZe YCM= IronPort-SDR: /ClwbW/SmOMkktyKV4s3/0TsTMTcGeokbwl2WyElDzXfL5kD/phGeTAaH8VsAF3y+a8ksKWGQD NwEQFxavhZJ9JFYci2jqnfX1QZcACuB76imQRn4dZdYpTgsY1xe5hP3J57IkpA1XhKOltieUfT 012GWmejGs4HqYXvnMbWqL4ZoF53wPRtNGD/VH81qmoA2zPiQfZaQe6cIrJTatGt9NDqBIWkO8 o5G2TA5TjlUZ35ecSzQUgV2yPwNaqjK4eIv1VZGPKJOwqldkg/cyNeTLkvBqpSTeoZL0tsdFix +/s= Date: Tue, 25 Feb 2020 14:36:48 +0000 From: Joseph Myers To: Lukasz Majewski CC: Andreas Schwab , Arnd Bergmann , Florian Weimer , Helmut Grohne , GNU C Library , Vineet Gupta , Palmer Dabbelt , Zong Li , , Alistair Francis , Adhemerval Zanella , "Maciej W. Rozycki" , Alistair Francis , arcml Subject: Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64) In-Reply-To: <20200225123945.10ec1c25@jawa> Message-ID: References: <4e95f95966d8d7c6a8339160dc62d81c1f6a1bfb.1578824547.git.alistair.francis@wdc.com> <00574bfb-981a-3a1c-cbdf-b2fee4eddc32@gmail.com> <8a9784b3-fc52-adc3-4595-33142b059388@synopsys.com> <20200220001136.2f14236e@jawa> <20200220103716.2f526933@jawa> <20200224100051.2511d797@jawa> <20200224111424.33759b2e@jawa> <20200224113658.275ea702@jawa> <20200225123945.10ec1c25@jawa> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" On Tue, 25 Feb 2020, Lukasz Majewski wrote: > Lets consider for example __mq_timedsend_time64. > > With lib_hidden_def/proto kept (NOT removed as in [1]): > GDB: > __GI___mq_timedsend_time64 [*] > > (No build errors, linking with test setup works as expected). What is the actual testcase, and the exact command line used to compile it? _TIME_BITS=64 redirection is only relevant for programs built with glibc, using the installed headers - not for building glibc itself. lib_hidden_proto is only relevant for building glibc, with its internal headers - not for programs built with glibc. If you're talking about a glibc testcase, such tests should be in tests not tests-internal, so _ISOMAC is defined when they are built, so the glibc internal headers just wrap the public ones without defining anything else. In particular, the asm redirections from public headers should be in effect when tests are compiled, but not the lib_hidden_proto redirections (but even for internal tests, lib_hidden_proto shouldn't do anything because the build process knows they are tests not part of libc). You should look at the preprocessed source from building the test with -save-temps and find out why the asm redirection from the public header isn't being effective (or if it is effective in the .o file for the test, look at what happens afterwards in glibc). Since lib_hidden_proto should not be called in the parts of headers included when building a test, its presence or absence should have no effect on the preprocessed source of the test. > hidden_def (__mq_timedsend) > weak_alias (__mq_timedsend, mq_timedsend) [**] > hidden_weak (mq_timedsend) If you have lib_hidden_weak note you also need a corresponding lib_hidden_proto, for the name of the weak alias. But you probably don't need to have lib_hidden* for the weak alias at all, just make sure internal calls use the internal name. -- Joseph S. Myers joseph@codesourcery.com