mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: sidneym@codeaurora.org
Cc: musl@lists.openwall.com
Subject: Re: [musl][hexagon] testing updates
Date: Fri, 17 Apr 2020 13:34:54 -0400	[thread overview]
Message-ID: <20200417173454.GJ11469@brightrain.aerifal.cx> (raw)
In-Reply-To: <173801d614db$c2cd8310$48688930$@codeaurora.org>

On Fri, Apr 17, 2020 at 12:15:13PM -0500, sidneym@codeaurora.org wrote:
> 
> 
> > -----Original Message-----
> > From: 'Rich Felker' <dalias@libc.org>
> > Sent: Thursday, April 16, 2020 11:18 AM
> > To: sidneym@codeaurora.org
> > Cc: musl@lists.openwall.com
> > Subject: Re: [musl][hexagon] testing updates
> > 
> > On Thu, Apr 16, 2020 at 11:05:36AM -0500, sidneym@codeaurora.org wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Rich Felker <dalias@libc.org>
> > > > Sent: Wednesday, April 15, 2020 10:16 PM
> > > > To: sidneym@codeaurora.org
> > > > Cc: musl@lists.openwall.com
> > > > Subject: Re: [musl][hexagon] testing updates
> > > >
> > > > On Wed, Apr 15, 2020 at 10:10:20PM -0500, sidneym@codeaurora.org
> > wrote:
> > > > > Updated alltypes.h.in and added sem.h.  This change cleared the
> > > > > following
> > > > > errors:
> > > > >
> > > > >       src/functional/pthread_mutex-static.exe
> > > > >
> > > > >       src/functional/pthread_mutex.exe
> > > > >
> > > > >       src/functional/pthread_mutex_pi-static.exe
> > > > >
> > > > >       src/functional/pthread_mutex_pi.exe
> > > > >       src/functional/sem_init-static.exe
> > > > >
> > > > >       src/functional/sem_init.exe
> > > >
> > > > I'm confused how these changed at all from the changes you made.
> > > > sem_init is for POSIX semaphores not sysv ipc ones. The bits/sem.h
> > > > things don't have anything to do with it.
> > >
> > > The sem.h change shouldn't have been included in the patch.
> > > The change of time_t from a 64 to 32 bit value changed the size of
> > > timespec used in the pthread_cond and sem_timedwait
> > >
> > > I pruned our original port, possibly too much in some cases, but in
> > > this case I'd like some guidance since no other arch needed time_t as
> > > a 32-bit type.
> > 
> > Remove the time_t and suseconds_t TYPEDEFs from alltypes.h.in. They are
> > no longer allowed to vary per-arch. Then make sure you rebuild
> > *everything* (libc, the test suite, any other code you're linking against
> musl
> > and trying to use). I'm pretty sure you have a mix of files that have been
> > build with different things you've tried and that is the source of your
> > problems.
> > 
> > > There is a large chunk of code compat/time32 which I have not tried to
> > > use yet but I have a feeling I might need to.
> > 
> > These files are only used on archs that had an old ABI with 32-bit time_t,
> > which I asked about before and you seemed to say you don't have. If you
> > *do* actually have an existing ecosystem of stuff that possibly needs to
> keep
> > working, we need to figure out what that is and whether it's even possible
> to
> > support (it might not be if it's a mess/mix of different things you've
> tried). If
> > not then these files will not even be built and are not needed.
> > 
> This isn't something I had understood very well.  Since Hexagon's unistd.h
> defines __ARCH_WANT_TIME32_SYSCALLS then we are using the old ABI I believe.

No, that's a matter of what interfaces the kernel provides. It has
nothing to do with musl always having 64-bit time_t.

> At the moment I don't feel very strongly about maintaining this, that might
> change the more I learn.  I'm looking at what it would take to migrate away
> from this.

There's no reason to migrate away from that. It doesn't affect
userspace applications at all; it's just a matter of syscall interface
stability. If you want to remove them, it can only be done before
there's a stable interface, and you would also have to remove the
syscall numbers from musl's arch/hexagon/bits/syscall.h.in or musl
will (rightly, by kernel stability policy) assume it can use them.

Rich

      reply	other threads:[~2020-04-17 17:35 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-16  3:10 sidneym
2020-04-16  3:16 ` Rich Felker
2020-04-16 16:05   ` sidneym
2020-04-16 16:17     ` 'Rich Felker'
2020-04-17 17:15       ` sidneym
2020-04-17 17:34         ` Rich Felker [this message]

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=20200417173454.GJ11469@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    --cc=sidneym@codeaurora.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.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

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