[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sun, 6 Dec 2015 21:58:08 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: SPARC Support
For the future, please avoid top-posting on the list; it makes it hard
to follow replies.
On Sun, Dec 06, 2015 at 06:08:58PM -0500, Administrator wrote:
> So does arch/bits/*.h define all of the kernel interfaces musl
> needs, or does it overwrite hard-coded defaults elsewhere in the
> code? I'll take a look at the aarch64 port, musl is something i'd
> really like to implement on our sparc machines, so this will
> probably be something i tackle over the next few months.
Right now, the bits headers have to define everything that actually
varies by arch, and the set of what "varies by arch" may have to be
expanded to accommodate sparc.
Part of the build system overhaul I'm still trying to accomplish in
this release cycle is getting rid of the duplication this implies and
building the arch-specific bits layered on top of base generic bits
and possibly other semi-generic layers for commonalities shared
between lots of archs. But if you want to start now, we can sort out
the changes later, either when sparc support is merged or afterwards.
> On 12/6/2015 8:52 AM, Szabolcs Nagy wrote:
> >* Administrator <administrator@...tagetitle.com> [2015-12-06 02:01:50 -0500]:
> >>Is there anyone working on supporting this architecture? I am using glibc
> >>for now until i can get musl to compile on it. I am correct, in a perfect
> >>world, that all i need is to put the necessary files in /arch and fix up the
> >>configure script to accept the correct ARCH variable?
> >>
> >someone on irc looked at sparc about half a year ago,
> >but i don't know how far that got.
> >
> >git log --stat 01ef3dd9c5fa7a56aa370f244dd08e05c73010f5
> >
> >shows which files were changed in the aarch64 port,
> >most of them are mandatory for a port.
> >
> >>Does the /arch dir simply override pre-existing definitions in musl, or are
> >>there certain files that absolutely have to be there? I see powerpc there,
> >>which allows me to assume that most of the work regarding endianess is
> >>already there.
> >endianness is not an issue (there is nothing in musl
> >that can meaningfully depend on endianness.. except
> >some linux syscall api structs need endian dependent
> >paddings, but that's target specific code).
> >
> >the real issue is that the linux kernel interfaces
> >for sparc have a lot of gratuitous incompatibilities
> >with other targets so doing arch/sparc/bits/*.h
> >is a significant amount of work.
The register windows stuff might also be a mess for how setjmp/longjmp
and related things like thread cancellation work.
Rich
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.
