This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
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)
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Lukasz Majewski <lukma at denx dot de>
- Cc: Andreas Schwab <schwab at suse dot de>, Arnd Bergmann <arnd at arndb dot de>, Florian Weimer <fweimer at redhat dot com>, Helmut Grohne <helmutg at debian dot org>, GNU C Library <libc-alpha at sourceware dot org>, Vineet Gupta <Vineet dot Gupta1 at synopsys dot com>, Palmer Dabbelt <palmerdabbelt at google dot com>, Zong Li <zongbox at gmail dot com>, <debian-arm at lists dot debian dot org>, Alistair Francis <alistair dot francis at wdc dot com>, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, "Maciej W. Rozycki" <macro at wdc dot com>, Alistair Francis <alistair23 at gmail dot com>, arcml <linux-snps-arc at lists dot infradead dot org>
- Date: Wed, 26 Feb 2020 14:48:40 +0000
- 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)
- Ironport-sdr: LStDd3KE9bm+GzjTTHOUCDrrO2XfrRFta4G5b518lrmzCYZt3fUKyO9TGfD97snt/EeIaZwUzr 8pZ+TmnrjPzbXABitAj7oYELsK+gRwqLunAcA7L52qWRFqZ4nsv/F2dhSgdUbGFqObp4WQK3PL riy3x5oFNN5sTfxbyRTjD6hCE8BO+ZxU/tvjkqLnwz8vvJR7bwonoRpYB1zzrGEMLlRVNvt7ao 5qJ1xDbXmRxhURWX9cthEkH3aG4zXdI/u4G0ryFVGsiBKQzLgsw6Ni12vWUz60RhgLj4J+GngZ 8cM=
- Ironport-sdr: lxmzzW6zbodHB2X6a5JpHbC6FMdPbq+Fm2h2mkG/tta7txxhxxjPRN61PY8gv9BK4+IJhzmTdS KI5NASNTtQK0ccznFFwJpyOgUtwxTPBWxuggCtWvnQxm9f3M3+LMflGD1ES2aowhmFX1re3/Qj dH7e8k+j1M00AFbYfUmiFi8zHVODYpTADVlwDWd//tAcavhF8XnuHBTHqltOghqdutVlit3Qtt BB8DDdjYoxm47qZJPAmhy6SlCxxZyWDg+R6udPNRT0ORUVR/etwHNxXRZEM03lHLp4bRFhA0sO suM=
- References: <cover.1578824547.git.alistair.francis@wdc.com> <00574bfb-981a-3a1c-cbdf-b2fee4eddc32@gmail.com> <CAKmqyKMyf2psPp+-EHoidvbPbSXv0=dP26GjVQnT5BUriLc1gA@mail.gmail.com> <alpine.DEB.2.21.2002120123230.3988@digraph.polyomino.org.uk> <CAKmqyKOgFRfMOws_-48GqMnuS3ygmN9A4DzLg6UtEjRXVoM82A@mail.gmail.com> <8a9784b3-fc52-adc3-4595-33142b059388@synopsys.com> <20200220001136.2f14236e@jawa> <CAK8P3a1b73K+RjfHONWLy_dFUucXxwd+0jTnHmkf6YqwRjit4w@mail.gmail.com> <20200220103716.2f526933@jawa> <CAK8P3a2n6fRm4C5Ywyk5ys92jSOAc5SwvBVZyFOY9=4rB2pyjw@mail.gmail.com> <20200224100051.2511d797@jawa> <mvmpne4xqpb.fsf@suse.de> <20200224111424.33759b2e@jawa> <mvmh7zgxozs.fsf@suse.de> <20200224113658.275ea702@jawa> <alpine.DEB.2.21.2002242353570.23654@digraph.polyomino.org.uk> <20200225123945.10ec1c25@jawa> <alpine.DEB.2.21.2002251427240.25788@digraph.polyomino.org.uk> <20200226141842.652ebbcc@jawa>
On Wed, 26 Feb 2020, Lukasz Majewski wrote:
> > > hidden_def (__mq_timedsend)
> > > weak_alias (__mq_timedsend, mq_timedsend) [**]
> > > hidden_weak (mq_timedsend)
> >
> > If you have lib<name>_hidden_weak note you also need a corresponding
> > lib<name>_hidden_proto, for the name of the weak alias. But you
> > probably don't need to have lib<name>_hidden* for the weak alias at
> > all, just make sure internal calls use the internal name.
>
> As fair as I can tell the weak_alias () is necessary for correct
> operation of mq_timedsend when external programs call it.
I wasn't commenting on the weak_alias call, but on the hidden_weak one.
If you have hidden_weak (mq_timedsend), you also need
lib<name>_hidden_proto (mq_timedsend) in the internal header (and vice
versa, hidden_proto implies you need hidden_weak).
You don't need hidden_weak (mq_timedsend) unless there is an *internal
call to mq_timedsend from within the same library that defines it*.
Since such an internal call could just use __mq_timedsend instead, you
probably don't need hidden_weak / hidden_proto for mq_timedsend.
(If you don't have an internal call to __mq_timedsend, you don't need the
hidden_* for that name either.)
--
Joseph S. Myers
joseph@codesourcery.com