[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 11 May 2016 13:48:28 -0500
From: Bobby Bingham <koorogi@...rogi.info>
To: musl@...ts.openwall.com
Subject: Re: porting musl to RISCV-64
On Wed, May 11, 2016 at 09:32:16AM -0700, Gry Gunvor wrote:
> On Wed, May 11, 2016 at 4:25 AM, Szabolcs Nagy <nsz@...t70.net> wrote:
>
> > newlib is for baremetal development, you don't
> > need to use threading with it
>
> It's attempt at reentrancy support is causing me problems.
>
> > musl now has 32bit mips, mips64 and mipsn32 support as well.
> > these are different abis so they have to be separate ports,
> > same is true for the riscv targets.
>
> Your documentation does not seem to mention the MIPS64 port, but now
> that I look in arch, I see the directory for it.
This is a pretty new port. The documentation just hasn't been updated
yet.
>
> > there is a google summer of code project to add riscv support
> > http://www.openwall.com/lists/musl/2016/04/27/3
> > i think it is supposed to provide a working port within 1-2
> > months (?) so if you can wait you don't need to do much work.
>
> Suppose I can't wait and I attempt this myself. Right now I'm just
> trying to get a generic libc working. I do not want to handle
> multi-threading or signals. What can I omit? Are the
> non-portabilities isolated in arch/ ? That is, is there much more to
> it than cloning the arch/mips64 directory and hacking on it?
There are some bits of architecture-specific assembly scattered
elsewhere (crti/crtn, setjmp/longjmp, syscall, syscall_cp).
The __clone function which is used to create new threads is also used
internally to implement a couple other functions that aren't strictly
threading-related (eg, posix_spawn and a fallback version of faccessat),
so if you omit it those functions may also not be usable.
>
> atomic_arch.h: I think I can make all of these functions empty as I am
> not going to be using multi-threading, right?
These functions don't really need to be atomic for a single thread to
work, but they do still need to perform the correct operations. If you're
ignoring the atomicity required for multi-threaded code, these are all
trivial to implement in C.
>
> crt_arch.h: program startup; what is this doing in a libc
> implementation? doesn't the compiler handle this?
This has the entry point that is invoked by the kernel, and handles the
little bit of setup necessary for handing off control to C code.
>
> ksigaction.h: sorry, I'm not a hardware person; I suppose different
> hardware has a different default layout for a signal object? so this
> is not a thing determined by kernel software? I don't care to handle
> signals right now anyway.
This needs to match the kernel. Not all musl ports have this file.
Some use the generic version in src/internal/ksigaction.h
>
> pthread_arch.h: again, I think I can make all of these functions empty
> as I am not going to be using multi-threading.
This is code for working with the thread pointer and thread-local storage.
Even if you only have a single thread, this is still necessary. For
example, errno is thread-local and is accessed through the thread
pointer (see the definition of __errno_location).
>
> reloc.h: I can't figure out what this is.
It's definitions for the dynamic linker.
>
> syscall_arch.h: I've already written this for RISCV-64 (and so have
> the RISCV people).
>
> bits: to what extent is this MIPS64-specific? since there is *no*
> inline assembly, how come arch/generic/ doesn't do here?
A small amount of it depends on the hardware (fenv) or on the ABI
(alltypes). Most of it though just needs to match the kernel, and the
Linux kernel definitions vary by architecture.
--
Bobby
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
