Rust architecture status

[John Paul Adrian Glaubitz]

Please answer to pkg-rust-maintain...@lists.alioth.debian.org. Don't answer
to debian-ports@l.d.o (just let your mail client honor the Reply-To field).

Hello!

I would like to a quick heads-up regarding the architecture status of Rust
after having had at the possibilities to get it bootstrapped for the remaining
architectures in Debian.

This is as of Rust 1.24.

alpha
=

Status:

No port yet. But until around version version 3.1, LLVM used to have an
official port for Alpha. So porting LLVM and consequently to Alpha should
generally feasible if LLVM upstream would be willing to merge an Alpha
port of LLVM back in.

armel
=

Status:

Is generally supported; pre-compiled binaries from the Rust website
work but trying to bootstrap the Debian package results in LLVM
bailing out with:

"LLVM ERROR: Broken function found, compilation aborted!"

Necessary work:

Can be most likely get to work by using the embedded copy of LLVM
instead of Debian's llvm-toolchain-4.0 package. See also powerpc.

hppa


Status:

Currently no LLVM port that I know of. mrustc might be an alternative.

ia64


Status:

Same as for Alpha. The ia64 port of LLVM was never officially merged
though. But it was done by the original LLVM compiler team though when
ia64 was still cool.

m68k


Status:

I started adding the necessary bits and pieces in a branch for the
Rust compiler but since there is no complete LLVM port for m68k yet,
porting Rust to m68k is currently not possible. I'm very confident
it will happen in the future though. We might be able to use mrustc
in the meantime which compiles Rust code to C code which can then
be compiled using gcc.

Necessary work:

- https://github.com/M680x0/M680x0-llvm/blob/M680x0/lib/Target/M680x0/TODO.md
- Finish the work I started on Rust for m68k and get it merged upstream

mips


Status:

Both pre-compiled as well as freshly compiled binaries of the Rust
compiler crash quite early when trying to build the Rust compiler
natively on mips. See: http://paste.debian.net/1011381/

Necessary work:

Fix the above crash. Could also be a bug in LLVM.

mips64el


Status:

Rust compiler seems generally relatively stable and compiling the compiler
natively on mips64el will progress quite far but the linker will eventually
bail out with "error adding symbols: Bad value" (I accidentally pasted the
full backtrace into a pastebin with an expiration date :().

Necessary:

Fix the above crash. Could also be a bug in LLVM or binutils.

mipsel
==

Not tested. Most likely similar behavior as on mips.

powerpc
===

Status:

Trying to bootstrap the Rust compiler Debian package using Debian's LLVM
compiler through the llvm-toolchain-4.0 package eventually bails out
with:

"LLVM ERROR: Broken function found, compilation aborted!" (same as error
as on armel). Switching the Debian compiler to use the internal LLVM
copy let's the build almost finish. The build eventually fails with
Rust's fabricate tool crashing with an overflow.

powerpcspe
==

Status:

No official port. But since LLVM supports the SPE CPU extensions on
PowerPCSPE adding support for this architecture should be any more
complex than it was to add x32 support to Rust.

Otherwise, the compiler is expected to suffer from the same bugs as
on powerpc.

sparc
=

Status:

Some pieces were missing in Rust upstream which I have opened a pull
request for. Additional small changes will be necessary in packages
like cc-rs and possibly libc (the Rust package).

Otherwise, it should be as usable as Rust on sparc64. I expect Rust
on 32-bit sparc to become usable once the Gentoo folks get around
bootstrapping it. They're currently busy fixing their sparc port.

Necessary work:

Get missing pieces merged upstream. Actually bootstrap the compiler.

sparc64
===

Status:

As of version 1.24, the compiler is very stable and can be used to
compile itself, Cargo and the Rust code in Firefox and Thunderbird.
It has been bootstrapped in Debian.

However, both the testsuites for rustc and cargo do not pass all
tests on sparc64. Although, to be fair, the amount of tests in
both testsuites is crazy and SPARC might simply have some peculiarities
that the Rust people haven't been thinking about. SPARC has always
been the special snowflake of architectures when it comes to otherwise
subtle bugs.

Necessary work:

Fix the testsuites for rustc and cargo and make sure the issues are
resolved for sparc (32-bit) as well.

For the time being, the testsuites for cargo and rustc should be
ignored/disabled on sparc64.

x32
===

Status:

Compiler mostly works and can be used to build cargo but not itself,
crashes with: http://paste.debian.net/1011382/.

Also, crates like "time" and "filetime" still suffer from the fact
that x32 is a 32-bit architecture with a 64-bit kernel interface
(see: https://sourceware.org/bugzilla/show_bug.cgi?id=16437). As
a result, using libc::c_long doesn't work. We have to use "i64" on
x32 instead.

Necessary work:

Re: debian-9.0-sparc64-NETINST-1.iso (rel 2018-02-16T23:09:00) Networking issues on Blade 150

[Jerome Ibanes]

Hello Frank,

https://eskimo.com/~jibanes/sparc/idprom2.jpg

I did change the mac address, as you can see in the screenshot linked
above, but it lead to the same outcome. Could you think of anything
else I should try? I could change the byte at fff4dfd9 to 80, but I'm
afraid it would lead to the same result. I can't think the network
adapter is defective because I can use it on other operating systems,
and when configured manually (prior to the installer's network
configuration) it works fine, if/when I let the installer deal with
this, even manually assigning an ip address, I do not have network
connectivity at all.

On Thu, Feb 22, 2018 at 1:02 AM, Frank Scheiner  wrote:
> Hi Jerome,
>
> On 02/22/2018 01:23 AM, Jerome Ibanes wrote:
>>
>> Frank,
>>
>> Could you try the following in obp:
>> cd /pci@1f,0/ebus@c/eeprom@1,0
>> fff4bfd0 30 dump
>> and tell me the numbers in fff4bfd8 and fff4bfd9, I would like to know
>> if it's 01 80 or 01 83
>
>
> That must be the "(real) machine type" (the second byte only, which is the
> first byte of a hostid). Without looking at it, I can say from my banner
> message that I have "(01) 80" currently in there, but I don't know the
> original value. I hadn't recorded that information before my NVRAM battery
> was depleted and I couldn't find a banner message from a Blade 100 online,
> so assumed "80" is correct.
>
> [1] on page 17 shows it to be "83" for a Blade 150 (which seems to be
> correct, see below). On the other hand [2] on page 67 shows it to be "61"
> for a Blade 100 - which must be plain wrong as [3] lists it as starting with
> "8". Maybe it was "80" for Blade 100s that use the 08:00:20 block and "83"
> for Blade 100s that use the 00:03:ba block, which would make "80" actually
> wrong for my machine and used MAC address block.
>
> [1]:
> https://docs.oracle.com/cd/E19127-01/blade150.ws/816-4379-10/816-4379-10.pdf
>
> [2]:
> https://docs.oracle.com/cd/E19127-01/blade100.ws/806-3416-10/806-3416-10.pdf
>
> [3]:
> https://web.archive.org/web/20030116022314/http://sunsolve.sun.com:80/handbook_pub/Devices/IDPROM/IDPROM_Parts.html?wrapper=false
>
> But as my machine doesn't show any issues with IP address auto-configuration
> from the installer despite the assumed wrong "(real) machine type" in the
> hostid, it might be unrelated to your problem.
>
> Cheers,
> Frank

Re: debian-9.0-sparc64-NETINST-1.iso (rel 2018-02-16T23:09:00) Networking issues on Blade 150

[Frank Scheiner]

Hi Jerome,

On 02/22/2018 01:23 AM, Jerome Ibanes wrote:

Frank,

Could you try the following in obp:
cd /pci@1f,0/ebus@c/eeprom@1,0
fff4bfd0 30 dump
and tell me the numbers in fff4bfd8 and fff4bfd9, I would like to know
if it's 01 80 or 01 83


That must be the "(real) machine type" (the second byte only, which is 
the first byte of a hostid). Without looking at it, I can say from my 
banner message that I have "(01) 80" currently in there, but I don't 
know the original value. I hadn't recorded that information before my 
NVRAM battery was depleted and I couldn't find a banner message from a 
Blade 100 online, so assumed "80" is correct.


[1] on page 17 shows it to be "83" for a Blade 150 (which seems to be 
correct, see below). On the other hand [2] on page 67 shows it to be 
"61" for a Blade 100 - which must be plain wrong as [3] lists it as 
starting with "8". Maybe it was "80" for Blade 100s that use the 
08:00:20 block and "83" for Blade 100s that use the 00:03:ba block, 
which would make "80" actually wrong for my machine and used MAC address 
block.


[1]: 
https://docs.oracle.com/cd/E19127-01/blade150.ws/816-4379-10/816-4379-10.pdf


[2]: 
https://docs.oracle.com/cd/E19127-01/blade100.ws/806-3416-10/806-3416-10.pdf


[3]: 
https://web.archive.org/web/20030116022314/http://sunsolve.sun.com:80/handbook_pub/Devices/IDPROM/IDPROM_Parts.html?wrapper=false


But as my machine doesn't show any issues with IP address 
auto-configuration from the installer despite the assumed wrong "(real) 
machine type" in the hostid, it might be unrelated to your problem.


Cheers,
Frank