From: <sidneym@codeaurora.org>
To: <musl@lists.openwall.com>
Subject: RE: [musl] Hexagon DSP support
Date: Wed, 15 Apr 2020 12:50:21 -0500 [thread overview]
Message-ID: <029101d6134e$56d4ece0$047ec6a0$@codeaurora.org> (raw)
In-Reply-To: <20200415163015.GG11469@brightrain.aerifal.cx>
> -----Original Message-----
> From: Rich Felker <dalias@libc.org>
> Sent: Wednesday, April 15, 2020 11:30 AM
> To: sidneym@codeaurora.org
> Cc: musl@lists.openwall.com
> Subject: Re: [musl] Hexagon DSP support
>
> On Wed, Apr 15, 2020 at 08:19:29AM -0500, sidneym@codeaurora.org wrote:
> > Recently work has been done with clang/llvm/lld to extend support for
> > Qualcomm's Hexagon DSP to a Linux target. At this point the publicly
> > available LLVM tools are able to build and run Hexagon programs via
QEMU.
> > I've attached a patch that add the Hexagon bits to musl. The
> > optimized routines have been purposely omitted to keep the size and
> > complexity to a minimum.
> >
> > The changes are being mirrored here:
> > https://github.com/quic/musl/tree/hexagon
> > The QEMU mirror is here: https://github.com/quic/qemu A description of
> > the assembly language is here:
> > https://developer.qualcomm.com/download/hexagon/hexagon-v5x-
> programmer
> > s-refe
> > rence-manual.pdf?referrer=node/6116
> >
> > The objective is to have enough freely available tools and libraries
> > that any user could develop code for the DSP. The C-library is an
> > important part of that stack and this patch is intended to start a
> > discussion of what would need to happen in order for Hexagon to be
> added to the musl sources.
>
> Thanks for reaching out upstream and sharing this. I did a quick glance
over
> the port (mostly just arch/hexagon dir, not source dirs in any detail) and
what
> I've read so far looks good.
>
> One question I have: alltypes.h.in defines _REDIR_TIME64. Is this because
> there's an existing unofficial ABI in deployments that you don't want to
> break? If so that's probably okay, but if not it's not necessary or wanted
for
> new 32-bit archs to define this; if it's not defined, the unadorned symbol
> names will just be 64-bit versions, just like on 64-bit archs.
>
That was a copy/paste error and was responsible for a few libc-testsuite
failures:
ld.lld: error: undefined symbol: __dlsym_time64
I will correct that and update the source.
> > I've tested this using libc-test (git://repo.or.cz/libc-test) and 56
> > errors are reported. The support for Hexagon in QEMU is on-going and
> > while some of the errors (math) may be attributed to QEMU most also
> > happen on hardware. A good chunk fail due to floating point exception
> status or precision.
>
> Can you send the output report to the list or post it somewhere publicly
> accessible? I can probably give you a quick rundown on whether any of the
> failures are unexpected (on qemu or real hardware) and it will suggest
which
> parts of the source I (and others in the
> community) should focus on reviewing.
This is the list, the context associated with some of the failures can be
bulky so I hope the summary is ok. Let me know which failures are most
critical and I will try to fix those first. 51 failures after removing the
TIME64 define
FAIL src/api/main.exe [status 1]
FAIL src/functional/dlopen.exe [status 1]
FAIL src/functional/ipc_msg-static.exe [status 1]
FAIL src/functional/ipc_msg.exe [status 1]
FAIL src/functional/ipc_sem-static.exe [status 1]
FAIL src/functional/ipc_sem.exe [status 1]
FAIL src/functional/ipc_shm-static.exe [status 1]
FAIL src/functional/ipc_shm.exe [status 1]
FAIL src/functional/pthread_mutex-static.exe [status 1]
FAIL src/functional/pthread_mutex.exe [status 1]
FAIL src/functional/pthread_mutex_pi-static.exe [timed out]
FAIL src/functional/pthread_mutex_pi.exe [signal Segmentation fault]
FAIL src/functional/pthread_robust-static.exe [timed out]
FAIL src/functional/pthread_robust.exe [timed out]
FAIL src/functional/sem_init-static.exe [status 1]
FAIL src/functional/sem_init.exe [status 1]
FAIL src/functional/strptime-static.exe [status 1]
FAIL src/functional/strptime.exe [status 1]
FAIL src/functional/utime-static.exe [status 1]
FAIL src/functional/utime.exe [status 1]
FAIL src/math/acoshl.exe [status 1]
FAIL src/math/asinhl.exe [status 1]
FAIL src/math/erfcl.exe [status 1]
FAIL src/math/exp2l.exe [status 1]
FAIL src/math/fmal.exe [status 1]
FAIL src/math/ilogb.exe [status 1]
FAIL src/math/ilogbf.exe [status 1]
FAIL src/math/ilogbl.exe [status 1]
FAIL src/math/lgammal.exe [status 1]
FAIL src/math/powf.exe [status 1]
FAIL src/math/powl.exe [status 1]
FAIL src/math/sqrt.exe [status 1]
FAIL src/math/sqrtf.exe [status 1]
FAIL src/math/sqrtl.exe [status 1]
FAIL src/math/tgamma.exe [status 1]
FAIL src/math/tgammaf.exe [status 1]
FAIL src/math/tgammal.exe [status 1]
FAIL src/math/y0.exe [status 1]
FAIL src/math/y0f.exe [status 1]
FAIL src/math/y1.exe [status 1]
FAIL src/math/y1f.exe [status 1]
FAIL src/math/yn.exe [status 1]
FAIL src/math/ynf.exe [status 1]
FAIL src/regression/malloc-brk-fail-static.exe [status 1]
FAIL src/regression/malloc-brk-fail.exe [timed out]
FAIL src/regression/pthread-robust-detach-static.exe [status 1]
FAIL src/regression/pthread-robust-detach.exe [status 1]
FAIL src/regression/pthread_cond-smasher-static.exe [status 1]
FAIL src/regression/pthread_cond-smasher.exe [status 1]
FAIL src/regression/pthread_cond_wait-cancel_ignored-static.exe [status 1]
FAIL src/regression/pthread_once-deadlock-static.exe [status 1]
>
> Rich
next prev parent reply other threads:[~2020-04-15 17:50 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-15 13:19 sidneym
2020-04-15 16:30 ` Rich Felker
2020-04-15 17:50 ` sidneym [this message]
2020-04-15 18:06 ` Szabolcs Nagy
2020-04-15 18:22 ` sidneym
2020-04-16 9:36 ` Szabolcs Nagy
2020-04-16 15:34 ` Rich Felker
2020-04-16 16:26 ` sidneym
2020-04-16 16:34 ` 'Rich Felker'
2020-04-15 18:26 ` Rich Felker
2020-04-15 19:12 ` sidneym
2020-04-15 19:29 ` 'Rich Felker'
2020-04-30 22:44 ` sidneym
2020-04-30 23:51 ` Rich Felker
2020-05-05 23:37 ` sidneym
2020-05-06 0:59 ` Rich Felker
2020-06-18 16:37 ` sidneym
2020-06-18 21:42 ` Szabolcs Nagy
2020-06-19 21:58 ` sidneym
2020-06-19 22:46 ` Rich Felker
2020-06-20 0:03 ` [musl] strtok Robert Skopalík
2020-06-20 0:15 ` Rich Felker
2020-06-20 0:36 ` Robert Skopalík
2020-06-20 0:46 ` Robert Skopalík
2020-06-20 1:44 ` Rich Felker
2020-06-20 7:07 ` Patrick Oppenlander
2020-06-20 13:00 ` Robert Skopalík
2020-06-22 0:57 ` Bery Saidi
2020-06-20 2:29 ` [musl] Hexagon DSP support sidneym
2020-06-20 3:20 ` Rich Felker
2020-07-20 21:26 ` sidneym
2020-07-23 21:56 ` Szabolcs Nagy
2020-07-24 17:49 ` sidneym
2020-09-16 20:49 ` sidneym
2020-09-17 1:32 ` 'Rich Felker'
2020-09-17 22:31 ` sidneym
2020-09-18 1:08 ` Rich Felker
2020-09-18 8:10 ` Szabolcs Nagy
2020-09-20 13:12 ` sidneym
2020-09-20 17:17 ` 'Rich Felker'
2020-09-21 14:09 ` sidneym
2020-04-15 18:55 ` Fangrui Song
2021-03-09 20:25 sidneym
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='029101d6134e$56d4ece0$047ec6a0$@codeaurora.org' \
--to=sidneym@codeaurora.org \
--cc=musl@lists.openwall.com \
/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).