This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v4 01/13] C-SKY: ABI related code
- From: "Manuel A. Fernandez Montecelo" <manuel dot montezelo at gmail dot com>
- To: Palmer Dabbelt <palmer at sifive dot com>
- Cc: fweimer at redhat dot com, Karsten Merker <merker at debian dot org>, "Manuel A. Fernandez Montecelo" <mafm at debian dot org>, DJ Delorie <dj at redhat dot com>, "Richard W.M. Jones" <rjones at redhat dot com>, David Abdurachmanov <david dot abdurachmanov at gmail dot com>, han_mao at c-sky dot com, hjl dot tools at gmail dot com, c-sky_gcc_upstream at c-sky dot com, gnu-csky at mentor dot com, GNU C Library <libc-alpha at sourceware dot org>
- Date: Sun, 30 Sep 2018 11:03:16 +0200
- Subject: Re: [PATCH v4 01/13] C-SKY: ABI related code
- References: <0f0b5b18-056b-c622-e313-74bf714ecb2a@redhat.com> <mhng-13753add-0b55-4ee7-87e1-ce750c33c9db@palmer-si-x1c4>
Hi,
Em sáb, 29 de set de 2018 às 03:46, Palmer Dabbelt <palmer@sifive.com> escreveu:
>
> On Wed, 12 Sep 2018 01:23:29 PDT (-0700), fweimer@redhat.com wrote:
> > On 09/12/2018 09:07 AM, Mao Han wrote:
> >> It seems used to call some pre-init function for libc, register transactional
> >> memory clone tables and invoke global constructors on C-SKY. Althrough I
> >> haven't found any constructors call by _init, I just tend to have _init and
> >> _fini as most other arch have these.
> >
> > The expectation is that for new glibc ports, GCC is tweaked to generate
> > the array variant of these constructs exclusively, like RISC-V did.
> > Then you won't need the function variant.
>
> I think we're the only ones who do it this way, but it appears to work and
> saves us a few symbols so I see no reason not to do so. In RISC-V land we're
> pretty aggressive about pruning old interfaces, but this one doesn't appear to
> have bitten us anywhere (or at least, has bitten us less than others :)).
>
> The distro guys are probably in a better place to comment on this decision,
> though, as this is one of those things that will only crop up in real code.
> I've added a few people who are more plugged in to these sorts of issues than I
> am.
What kind of error messages or behaviours would we see, if this is
used by any software packaged in the distros?
In the Debian port for riscv64, with ~85% of the whole archive
compiled, I don't remember seeing messages in packages that seemed
related to this, but maybe they manifest in non-obvious (for me) ways.
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montezelo@gmail.com>