mailing list of musl libc
 help / color / mirror / code / Atom feed
* [musl][hexagon] testing updates
@ 2020-04-16  3:10 sidneym
  2020-04-16  3:16 ` Rich Felker
  0 siblings, 1 reply; 6+ messages in thread
From: sidneym @ 2020-04-16  3:10 UTC (permalink / raw)
  To: musl

[-- Attachment #1: Type: text/plain, Size: 793 bytes --]

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

      src/regression/pthread_cond-smasher-static.exe

      src/regression/pthread_cond-smasher.exe

      src/regression/pthread_cond_wait-cancel_ignored-static.exe

      src/regression/pthread_cond_wait-cancel_ignored.exe

      src/regression/pthread_once-deadlock-static.exe

 

The patch is here:
https://github.com/quic/musl/commit/ca20acd472a8e9e58e584d51c4cd00ced6f37087

 

I will continue to examine the issues and follow up.

 

Thanks,

 


[-- Attachment #2: Type: text/html, Size: 3265 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [musl][hexagon] testing updates
  2020-04-16  3:10 [musl][hexagon] testing updates sidneym
@ 2020-04-16  3:16 ` Rich Felker
  2020-04-16 16:05   ` sidneym
  0 siblings, 1 reply; 6+ messages in thread
From: Rich Felker @ 2020-04-16  3:16 UTC (permalink / raw)
  To: sidneym; +Cc: musl

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.

>       src/regression/pthread_cond-smasher-static.exe
> 
>       src/regression/pthread_cond-smasher.exe
> 
>       src/regression/pthread_cond_wait-cancel_ignored-static.exe
> 
>       src/regression/pthread_cond_wait-cancel_ignored.exe
> 
>       src/regression/pthread_once-deadlock-static.exe

Likewise these shouldn't have changed either. If they did it's
probably some other hidden state in your test environment.

> The patch is here:
> https://github.com/quic/musl/commit/ca20acd472a8e9e58e584d51c4cd00ced6f37087

The change to alltypes.h.in is wrong. It changes time_t to 32-bit,
which is no longer a supported configuration and not the intent. With
that part reverted and the sysvipc bits headers fixed as described
before, I think you might have it mostly working.

Rich

^ permalink raw reply	[flat|nested] 6+ messages in thread

* RE: [musl][hexagon] testing updates
  2020-04-16  3:16 ` Rich Felker
@ 2020-04-16 16:05   ` sidneym
  2020-04-16 16:17     ` 'Rich Felker'
  0 siblings, 1 reply; 6+ messages in thread
From: sidneym @ 2020-04-16 16:05 UTC (permalink / raw)
  To: 'Rich Felker'; +Cc: musl



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


> 
> >       src/regression/pthread_cond-smasher-static.exe
> >
> >       src/regression/pthread_cond-smasher.exe
> >
> >       src/regression/pthread_cond_wait-cancel_ignored-static.exe
> >
> >       src/regression/pthread_cond_wait-cancel_ignored.exe
> >
> >       src/regression/pthread_once-deadlock-static.exe
> 
> Likewise these shouldn't have changed either. If they did it's probably
some
> other hidden state in your test environment.
> 
> > The patch is here:
> >
> https://github.com/quic/musl/commit/ca20acd472a8e9e58e584d51c4cd00ce
> d6
> > f37087
> 
> The change to alltypes.h.in is wrong. It changes time_t to 32-bit, which
is no
> longer a supported configuration and not the intent. With that part
reverted
> and the sysvipc bits headers fixed as described before, I think you might
> have it mostly working.
> 
> Rich

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [musl][hexagon] testing updates
  2020-04-16 16:05   ` sidneym
@ 2020-04-16 16:17     ` 'Rich Felker'
  2020-04-17 17:15       ` sidneym
  0 siblings, 1 reply; 6+ messages in thread
From: 'Rich Felker' @ 2020-04-16 16:17 UTC (permalink / raw)
  To: sidneym; +Cc: musl

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.

Rich

^ permalink raw reply	[flat|nested] 6+ messages in thread

* RE: [musl][hexagon] testing updates
  2020-04-16 16:17     ` 'Rich Felker'
@ 2020-04-17 17:15       ` sidneym
  2020-04-17 17:34         ` Rich Felker
  0 siblings, 1 reply; 6+ messages in thread
From: sidneym @ 2020-04-17 17:15 UTC (permalink / raw)
  To: musl



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

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.

Thanks,


> Rich

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [musl][hexagon] testing updates
  2020-04-17 17:15       ` sidneym
@ 2020-04-17 17:34         ` Rich Felker
  0 siblings, 0 replies; 6+ messages in thread
From: Rich Felker @ 2020-04-17 17:34 UTC (permalink / raw)
  To: sidneym; +Cc: musl

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2020-04-17 17:35 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-16  3:10 [musl][hexagon] testing updates 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

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