linux-snps-arc.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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

  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).