SPARC Support

SPARC Support

[Administrator]

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?

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.



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: SPARC Support

[Szabolcs Nagy]

* Administrator <administrator@vantagetitle.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.

Re: SPARC Support

[Administrator]

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.

On 12/6/2015 8:52 AM, Szabolcs Nagy wrote:
> * Administrator <administrator@vantagetitle.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.


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: SPARC Support

[Rich Felker]

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