From: Adhemerval Zanella <adhemerval.zanella@linaro.org>
To: Vineet Gupta <Vineet.Gupta1@synopsys.com>,
"libc-alpha@sourceware.org" <libc-alpha@sourceware.org>
Cc: "linux-snps-arc@lists.infradead.org"
<linux-snps-arc@lists.infradead.org>
Subject: Re: [PATCH v6 11/13] ARC: Build Infrastructure
Date: Thu, 4 Jun 2020 14:05:52 -0300 [thread overview]
Message-ID: <98aad6dd-dd47-a5af-eb36-8203a080ee01@linaro.org> (raw)
In-Reply-To: <d64e6491-c5de-4c43-4e8e-d56ca77e662c@synopsys.com>
On 04/06/2020 12:25, Vineet Gupta wrote:
> On 6/3/20 12:58 PM, Adhemerval Zanella via Libc-alpha wrote:
>>
>>>
>>> diff --git a/config.h.in b/config.h.in
>>> index dea43df438f6..08962dfed075 100644
>>> --- a/config.h.in
>>> +++ b/config.h.in
>>> @@ -109,6 +109,9 @@
>>> /* AArch64 big endian ABI */
>>> #undef HAVE_AARCH64_BE
>>>
>>> +/* ARC big endian ABI */
>>> +#undef HAVE_ARC_BE
>>> +
>>
>> Why do you need this define exactly? It is not used anywhere in the code
>> and for C code if is more straightforwar to use endian.h.
>
> It is used in build system as part of "formal" BE ABI support as pointed to in v4
> series review. This specific thing helps choose the right dynamic linker name for
> BE case.
Ack.
>
> $ git grep HAVE_ARC_BE
> config.h.in:113:#undef HAVE_ARC_BE
> sysdeps/arc/configure:175: $as_echo "#define HAVE_ARC_BE 1" >>confdefs.h
> sysdeps/arc/configure.ac:22: AC_DEFINE(HAVE_ARC_BE)
> sysdeps/unix/sysv/linux/arc/shlib-versions:3:%ifdef HAVE_ARC_BE
>
> I looked at other ports and they seem to follow similar patters: csky for CSKYABI,
> riscv for RISCV_ABI_XLEN etc.
Right, it is the usual way indeed. This is fine.
>
> But I can rework if there's a simpler/better way.
>
>>> +++ b/sysdeps/arc/Versions
>>> @@ -0,0 +1,8 @@
>>> +libc {
>>> + GLIBC_2.32 {
>>> + __mcount;
>>> + }
>>
>> Hum, does ARC require a different symbol name than the one provided
>> by gmon/Versions?
>
> ARC gcc generates __mcount and _mcount with different ABIs and we use the newer
> __mcount.
Ack.
>
>>> +AC_DEFINE(PI_STATIC_AND_HIDDEN)
>>> +libc_cv_have_sdata_section=no
>>
>> The libc_cv_have_sdata_section is done by configure.ac, why do you need
>> to explicit set it here?
>
> We inhibit small data explicitly which by default kicks in.
Ok, is it some limitation for loader bootstrap or something else?
>
>>> +if test $libc_cv_arc_be = yes; then
>>> + # For shlib-versions.
>>> + AC_DEFINE(HAVE_ARC_BE)
>>> + LIBC_CONFIG_VAR([default-abi], [ilp32_be])
>>> +else
>>> + LIBC_CONFIG_VAR([default-abi], [ilp32])
>>> +fi
>>
>> The ilp32 naming is usually set for ILP32 architectures that uses
>> 64-bit registers type on 32 bit VMA (for instance mips64n32, x32,
>> or aarch64_ilp32). I don't think this is the case for ARC, so I think
>> this naming might be confusing.
>>> +abi-variants := ilp32 ilp32_be
>
> arcle arcbe ?
LGTM.
>
>>> +
>>> +ifeq (,$(filter $(default-abi),$(abi-variants)))
>>> +$(error Unknown ABI $(default-abi), must be one of $(abi-variants))
>>> +endif
>>> +
>>> +abi-ilp32-condition := !defined __BIG_ENDIAN__
>>> +abi-ilp32_be-condition := defined __BIG_ENDIAN__
>>
>> Ok with the 'ilp32' naming module described above.
>
>
>>> diff --git a/sysdeps/unix/sysv/linux/arc/Versions b/sysdeps/unix/sysv/linux/arc/Versions
>>> new file mode 100644
>>> index 000000000000..292f1974b02a
>>> --- /dev/null
>>> +++ b/sysdeps/unix/sysv/linux/arc/Versions
>>> @@ -0,0 +1,16 @@
>>> +ld {
>>> + GLIBC_PRIVATE {
>>> + # used for loading by static libraries
>>> + _dl_var_init;
>>> + }
>>> +}
>>> +libc {
>>> + GLIBC_2.32 {
>>> + _flush_cache;
>>> + cacheflush;
>>> + }
>>> + GLIBC_PRIVATE {
>>> + # A copy of sigaction lives in libpthread, and needs these.
>>> + __default_rt_sa_restorer;
>>> + }
>>> +}
>>
>> Afaik all other ABIs that requires the sa_restores uses a local symbol in
>> libpthread. I don't have a strong preference here.
>
> Do you mean add following to sysdeps/unix/sysv/linux/arc/Makefile
>
> ifeq ($(subdir),nptl)
> libpthread-routines += sigrestorer
> libpthread-shared-only-routines += sigrestorer
> endif
Yeap.
>
> And that is to optimize the reference to restorer as a direct PC relative access
> vs a got reference ?
My understanding is this specific optimization does not really matter:
sigaction is hardly a hotspot and the symbol will be issue by the
kernel itself. AFAIU is more a way to optimize the exported symbols
and simplify the GLIBC_PRIVATE namespace (since the sa_restore usually
has small text size).
>
> It seems even in libc, this is currently not optimal. It seems we need
> libc_hidden_* on restorer.
>
> 0002b020 <__GI___libc_sigaction>:
> 2b020: std.aw r14r15,[sp,-8]
> 2b024: push_s r13
> 2b026: sub_s sp,sp,0x28
> ...
> 2b02e: mov_s r3,r1
> 2b030: ld r13,[pcl,0xd4e9c] <__default_rt_sa_restorer@@GLIBC_PRIVATE+0xd4558>
>
If you define it as attribute_hidden and add on both libc and libpthread it
should not require the libc_hidden_{proto,def}.
>
>
>>> diff --git a/sysdeps/unix/sysv/linux/arc/shlib-versions b/sysdeps/unix/sysv/linux/arc/shlib-versions
>>> new file mode 100644
>>> index 000000000000..343c0a04500e
>>> --- /dev/null
>>> +++ b/sysdeps/unix/sysv/linux/arc/shlib-versions
>>> @@ -0,0 +1,7 @@
>>> +DEFAULT GLIBC_2.32
>>> +
>>> +%ifdef HAVE_ARC_BE
>
> This is where the BE define is used.
>
>>> +ld=ld-linux-arceb.so.2
>>> +%else
>>> +ld=ld-linux-arc.so.2
>>> +%endif
>
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
next prev parent reply other threads:[~2020-06-04 17:06 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-23 1:41 [PATCH v6 00/13] glibc port to ARC processors Vineet Gupta
2020-04-23 1:41 ` [PATCH v6 01/13] ARC: ABI Implementation Vineet Gupta
[not found] ` <88508d10-2d29-026a-bb54-ad607154ab87@linaro.org>
2020-05-27 22:15 ` Vineet Gupta
2020-05-29 13:56 ` Adhemerval Zanella
[not found] ` <a56a35d4-3e9e-9a88-4be5-8553d5f11ad3@synopsys.com>
[not found] ` <87mu5jxkv7.fsf@oldenburg2.str.redhat.com>
2020-06-04 19:01 ` Vineet Gupta
2020-06-04 23:56 ` Vineet Gupta
2020-04-23 1:41 ` [PATCH v6 02/13] ARC: startup and dynamic linking code Vineet Gupta
[not found] ` <17957ee6-2bc1-f43b-f184-f0703ba2765f@linaro.org>
2020-05-28 1:14 ` Vineet Gupta
2020-04-23 1:41 ` [PATCH v6 03/13] ARC: Thread Local Storage support Vineet Gupta
[not found] ` <4f7a67fb-6f96-57e6-b827-d1ab5dd6733f@linaro.org>
2020-05-28 1:36 ` Vineet Gupta
2020-06-01 18:53 ` Adhemerval Zanella
2020-04-23 1:41 ` [PATCH v6 04/13] ARC: Atomics and Locking primitives Vineet Gupta
[not found] ` <03f4a9b3-b1ca-90fa-0b6a-609a3135267d@linaro.org>
2020-04-24 7:23 ` Vineet Gupta
[not found] ` <20200427215938.14136-1-vgupta@synopsys.com>
2020-04-27 22:13 ` [PATCH] semaphore: consolidate arch headers into a generic one Vineet Gupta
[not found] ` <ac93c301-36d3-b20a-d31c-50c1f3264c68@linaro.org>
2020-05-05 22:59 ` Vineet Gupta
2020-05-08 13:32 ` Adhemerval Zanella
2020-04-23 1:41 ` [PATCH v6 05/13] ARC: math soft float support Vineet Gupta
2020-04-23 1:41 ` [PATCH v6 06/13] ARC: hardware floating point support Vineet Gupta
2020-05-29 14:12 ` Adhemerval Zanella
2020-05-29 22:28 ` Vineet Gupta
2020-05-29 23:50 ` Vineet Gupta
2020-06-02 17:51 ` Joseph Myers
[not found] ` <07887c48-7e07-9f89-035d-3f336a16f2da@synopsys.com>
2020-06-02 18:13 ` static inline math functions (was Re: [PATCH v6 06/13] ARC: hardware floating point support) Joseph Myers
2020-06-02 18:35 ` Adhemerval Zanella
2020-06-05 4:44 ` [PATCH v6 06/13] ARC: hardware floating point support Vineet Gupta
2020-06-05 17:22 ` Adhemerval Zanella
2020-06-02 17:48 ` Joseph Myers
2020-04-23 1:41 ` [PATCH v6 07/13] ARC: Linux Syscall Interface Vineet Gupta
2020-05-29 16:49 ` Adhemerval Zanella
2020-05-30 2:02 ` Vineet Gupta
2020-06-03 19:46 ` Vineet Gupta
2020-06-03 20:04 ` Adhemerval Zanella
2020-06-03 20:17 ` Vineet Gupta
2020-06-04 11:06 ` Adhemerval Zanella
2020-04-23 1:41 ` [PATCH v6 08/13] ARC: Linux ABI Vineet Gupta
2020-04-23 1:41 ` [PATCH v6 09/13] ARC: Linux Startup and Dynamic Loading Vineet Gupta
2020-04-23 1:41 ` [PATCH v6 10/13] ARC: ABI lists Vineet Gupta
2020-04-23 1:41 ` [PATCH v6 11/13] ARC: Build Infrastructure Vineet Gupta
2020-06-03 19:58 ` Adhemerval Zanella
2020-06-04 15:25 ` Vineet Gupta
2020-06-04 17:05 ` Adhemerval Zanella [this message]
2020-06-08 4:18 ` Vineet Gupta
2020-04-23 1:41 ` [PATCH v6 12/13] build-many-glibcs.py: Enable ARC builds Vineet Gupta
2020-04-23 1:41 ` [PATCH v6 13/13] Documentation for ARC port Vineet Gupta
2020-05-04 21:21 ` [PATCH v6 00/13] glibc port to ARC processors Vineet Gupta
2020-05-15 0:45 ` Vineet Gupta
2020-05-27 1:49 ` Vineet Gupta
[not found] ` <d7f1176c-87c6-90c6-161c-4705a47837ea@linaro.org>
2020-05-27 18:38 ` Vineet Gupta
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=98aad6dd-dd47-a5af-eb36-8203a080ee01@linaro.org \
--to=adhemerval.zanella@linaro.org \
--cc=Vineet.Gupta1@synopsys.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-snps-arc@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).