public inbox for libc-help@sourceware.org
 help / color / mirror / Atom feed
From: Mao Han <han_mao@c-sky.com>
To: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Cc: c-sky_gcc_upstream@c-sky.com, gnu-csky@mentor.com,
	libc-help@sourceware.org
Subject: Re: [RFC PATCH 10/10] C-SKY: Linux ABI
Date: Tue, 20 Mar 2018 10:58:00 -0000	[thread overview]
Message-ID: <20180320105842.GA19381@vmh-VirtualBox> (raw)
In-Reply-To: <3b2ad134-f258-cd13-8713-6225903ef255@linaro.org>

Hi Adhemerval,
Thanks a lot for the comment.

On Tue, Mar 20, 2018 at 05:41:59PM +0800, Adhemerval Zanella wrote:
> 
> 
> On 16/03/2018 17:58, Mao Han wrote:
> > diff --git a/sysdeps/unix/sysv/linux/csky/sysdep-cancel.h b/sysdeps/unix/sysv/linux/csky/sysdep-cancel.h
> > new file mode 100644
> > index 0000000..dd39ecf
> > --- /dev/null
> > +++ b/sysdeps/unix/sysv/linux/csky/sysdep-cancel.h
> 
> New ports should not provide sysdep-cancel.h any more, cancellable syscall
> not generated by syscalls.list and if it an advantage for the ABI, it
> can define SINGLE_THREAD_BY_GLOBAL on sysdep.h (so the single-thread
> check will be done by a global variable instead of using a TCB field).
>

OK. I'll remove csky/sysdep-cancel.h, Seems no dependece on this file
as ./socket.S is nolonger used. We are suggest to use __ASSUME_SOCKET_SYSCALL
while upsteam linux kernel. So no need to keep these files.

> > +#if defined (EWOULDBLOCK_sys) && EWOULDBLOCK_sys != EAGAIN
> > +        /* We translate the system's EWOULDBLOCK error into EAGAIN.
> > +           The GNU C library always defines EWOULDBLOCK==EAGAIN.
> > +           EWOULDBLOCK_sys is the original number.  */
> > +        cmpnei  a0, EWOULDBLOCK	/* Is it the old EWOULDBLOCK?  */
> > +        bt      1f
> > +        mov     a0, EAGAIN	/* Yes; translate it to EAGAIN.  */
> > +#endif
> 
> I am not sure if this is true or required for new ports, does C-SKY
> really require this code snippet?
>

Carlos O'Donell mentions this too. It is not required for new ports.
We do not have legacy UNIX port, It is always true EWOULDBLOCK==EAGAIN
In linux errno.h
#define      EWOULDBLOCK     EAGAIN  /* Operation would block */
I don't think C-SKY needs these code. I'll clean all these up.
 
> > +/* Pointer mangling is not yet supported for CSKY.  */
> > +#define PTR_MANGLE(var) (void) (var)
> > +#define PTR_DEMANGLE(var) (void) (var)
> 
> Is there any special reason to not support it? Other architecture accomplish
> by either using a global variable or a TCB field.

We haven't spent much time work on the safty and profile in glibc.
It seems not hard to implement it. I will add support for pointer mangling.

  reply	other threads:[~2018-03-20 10:58 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-16  9:59 [RFC PATCH 00/10] port C-SKY to glibc Mao Han
2018-03-16  9:59 ` [RFC PATCH 06/10] C-SKY: Build Infastructure Mao Han
2018-03-16  9:59 ` [RFC PATCH 10/10] C-SKY: Linux ABI Mao Han
2018-03-20  9:42   ` Adhemerval Zanella
2018-03-20 10:58     ` Mao Han [this message]
2018-03-16  9:59 ` [RFC PATCH 09/10] C-SKY: Linux Syscall Interface Mao Han
2018-03-18  3:19   ` Adhemerval Zanella
2018-03-20  6:36     ` Mao Han
2018-03-16  9:59 ` [RFC PATCH 08/10] C-SKY: ABI Lists Mao Han
2018-03-16  9:59 ` [RFC PATCH 03/10] C-SKY: Generic math Routines Mao Han
2018-03-16 14:13   ` Carlos O'Donell
2018-03-16  9:59 ` [RFC PATCH 02/10] C-SKY: TLS support Mao Han
2018-03-16 14:09   ` Carlos O'Donell
2018-03-20  4:57     ` Mao Han
2018-03-16  9:59 ` [RFC PATCH 05/10] C-SKY: Linux Startup and Dynamic Loading Code Mao Han
2018-03-16 14:37   ` Carlos O'Donell
2018-03-16  9:59 ` [RFC PATCH 04/10] C-SKY: Hard Float Support Mao Han
2018-03-16 14:15   ` Carlos O'Donell
2018-03-16  9:59 ` [RFC PATCH 07/10] C-SKY: Atomic and Locking Routines Mao Han
2018-03-16  9:59 ` [RFC PATCH 01/10] C-SKY: ABI related code Mao Han
2018-03-16 14:04   ` Carlos O'Donell
2018-03-16 13:52 ` [RFC PATCH 00/10] port C-SKY to glibc Carlos O'Donell

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=20180320105842.GA19381@vmh-VirtualBox \
    --to=han_mao@c-sky.com \
    --cc=adhemerval.zanella@linaro.org \
    --cc=c-sky_gcc_upstream@c-sky.com \
    --cc=gnu-csky@mentor.com \
    --cc=libc-help@sourceware.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 read-only IMAP folder(s) and NNTP newsgroup(s).