Re: Desktops on non-x86_64 systems

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

> Hi!
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> I've updated the branch wip-cross-built-rust; it seems to build and run
>> OK (although running the binary produced by compiling hello.rs with the
>> cross-built i686-linux rustc in a 32 bit VM took 47 sec (!?)),
>> apparently hanging on something before outputting correctly the message
>> and exiting with 0.
>>
>> I'd now like to figure out the top-level plumbing required to get this
>> rust-i686-linux x86-64 package accepted in the real of i686-linux
>> packages (cross the architecture boundary).  Is this even possible in
>> Guix?
>>
>> In other words, I'd like the i686 architecture to be able to use this
>> rust-i686-linux cross built from x86_64 as if it was a *native* package.
>
> It’s not possible as it would imply that i686 is able to run x86_64
> code.
>
> What we’d need to do is “cut the dependency graph” at the architecture
> boundary, similar to what’s described in
> <https://guix.gnu.org/manual/devel/en/html_node/Porting.html>.
>
> Concretely, we’d cross-build Rust for i686 once; we’d put it in a
> tarball, store it at ftp.gnu.org, and make the rust 1.54 package (or
> whatever that is) be equal so that tarball, unpacked, when the current
> system is i686.  (Similar to the ‘guile-bootstrap’ package.)

OK!  Good to know that it's been done before!  Thanks for the pointer.

> It does mean that the cross-built Rust must be statically linked.

OK.  That's probably not too difficult, given the cozy relationship Rust
enjoys with static linking.  Where does this requirement come from
though?  And would we need to use something else than glibc, as IIUC it
cannot be completely statically linked in the produced binaries.

> To reduce the risks associated with binary blobs, the Rust build should
> ideally be reproducible, so that anyone can verify that the thing we put
> at ftp.gnu.org is indeed Rust as cross-compiled from x86_64.
>
> How long is the road ahead in your opinion?

I currently have this runtime problem with the build, where the
correctly compiled hello.rs program below:

--8<---------------cut here---------------start------------->8---
$ cat hello.rs 
// This is a comment, and is ignored by the compiler
// You can test this code by clicking the "Run" button over there ->
// This is a comment, and is ignored by the compiler
// You can test this code by clicking the "Run" button over there ->
// or if you prefer to use your keyboard, you can use the "Ctrl + Enter" shortcut

// This code is editable, feel free to hack it!
// You can always return to the original code by clicking the "Reset" button ->

// This is the main function
fn main() {
    // Statements here are executed when the compiled binary is called

    // Print text to the console
    println!("Hello World!");
}

$ time rustc hello.rs

real	0m3.465s
user	0m1.113s
sys	0m1.217s

$ file hello
hello: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=5458fb195357d02ff6de3d429201d69c16f03e1b, for GNU/Linux 2.6.32, with debug_info, not stripped

$ time ./hello
Hello World!

real	0m41.361s
user	0m41.319s
sys	0m0.028s
--8<---------------cut here---------------end--------------->8---

41 s to print hello world, eh.

The problem seems to lie somewhere in the cross-compiled glibc, which
spends lots of time on initializing libpthreads and acquiring mutexes:

--8<---------------cut here---------------start------------->8---
# perf record --call-graph dwarf /path/to/hello_world
# perf report --no-inline
Samples: 12K of event 'cycles', Event count (approx.): 85948101927
  Children      Self  Command  Shared Object       Symbol
+   88.62%     0.00%  hello    libpthread-2.33.so  [.] _init
+   88.62%    11.37%  hello    libpthread-2.33.so  [.] __pthread_initialize_minimal_internal
+   41.84%    34.58%  hello    libpthread-2.33.so  [.] __pthread_mutex_lock_full
+   35.37%    35.18%  hello    libpthread-2.33.so  [.] __pthread_mutex_lock
+   11.19%    11.16%  hello    libpthread-2.33.so  [.] __x86.get_pc_thunk.di
+    7.10%     7.02%  hello    libpthread-2.33.so  [.] __x86.get_pc_thunk.si
     0.59%     0.14%  hello    [kernel.kallsyms]   [k] apic_timer_interrupt
     0.45%     0.00%  hello    [kernel.kallsyms]   [k] smp_apic_timer_interrupt
     0.35%     0.00%  hello    [kernel.kallsyms]   [k] hrtimer_interrupt
     0.28%     0.02%  hello    [kernel.kallsyms]   [k] __hrtimer_run_queues
     0.25%     0.00%  hello    [kernel.kallsyms]   [k] tick_sched_timer
     0.19%     0.00%  hello    [kernel.kallsyms]   [k] tick_sched_handle
     0.19%     0.01%  hello    [kernel.kallsyms]   [k] update_process_times
     0.16%     0.00%  hello    [unknown]           [k] 0xf4a15ff8
     0.13%     0.01%  hello    [kernel.kallsyms]   [k] scheduler_tick
     0.05%     0.01%  hello    [kernel.kallsyms]   [k] irq_exit
     0.05%     0.00%  hello    [kernel.kallsyms]   [k] tick_sched_do_timer
     0.05%     0.00%  hello    [kernel.kallsyms]   [k] tick_do_update_jiffies64.part.12
     0.05%     0.05%  hello    [kernel.kallsyms]   [k] native_write_msr
     0.04%     0.00%  hello    [kernel.kallsyms]   [k] try_to_wake_up
     0.04%     0.04%  hello    [kernel.kallsyms]   [k] restore_all
     0.04%     0.00%  hello    [kernel.kallsyms]   [k] call_on_stack
     0.04%     0.00%  hello    [kernel.kallsyms]   [k] do_softirq_own_stack
     0.04%     0.01%  hello    [kernel.kallsyms]   [k] ktime_get_update_offsets_now
     0.04%     0.01%  hello    [kernel.kallsyms]   [k] perf_event_task_tick
     0.04%     0.01%  hello    [kernel.kallsyms]   [k] perf_pmu_disable.part.92
     0.04%     0.00%  hello    [kernel.kallsyms]   [k] irq_work_interrupt
     0.04%     0.00%  hello    [kernel.kallsyms]   [k] smp_irq_work_interrupt
--8<---------------cut here---------------end--------------->8---

gdb reports:

--8<---------------cut here---------------start------------->8---
(gdb) set auto-load safe-path /
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/user/Desktop/hello
BFD: warning: /gnu/store/miwzifnpn3lgzd6kvkcmz1i0hx7vvdfm-glibc-cross-i686-linux-gnu-2.33/lib/../lib/libpthread.so.0: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0008002
BFD: warning: /gnu/store/miwzifnpn3lgzd6kvkcmz1i0hx7vvdfm-glibc-cross-i686-linux-gnu-2.33/lib/../lib/libpthread.so.0: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010001
BFD: warning: /gnu/store/miwzifnpn3lgzd6kvkcmz1i0hx7vvdfm-glibc-cross-i686-linux-gnu-2.33/lib/../lib/libpthread.so.0: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010002
BFD: warning: /gnu/store/miwzifnpn3lgzd6kvkcmz1i0hx7vvdfm-glibc-cross-i686-linux-gnu-2.33/lib/../lib/libdl.so.2: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0008002
BFD: warning: /gnu/store/miwzifnpn3lgzd6kvkcmz1i0hx7vvdfm-glibc-cross-i686-linux-gnu-2.33/lib/../lib/libdl.so.2: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010001
BFD: warning: /gnu/store/miwzifnpn3lgzd6kvkcmz1i0hx7vvdfm-glibc-cross-i686-linux-gnu-2.33/lib/../lib/libdl.so.2: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010002
BFD: warning: /gnu/store/miwzifnpn3lgzd6kvkcmz1i0hx7vvdfm-glibc-cross-i686-linux-gnu-2.33/lib/../lib/libc.so.6: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0008002
BFD: warning: /gnu/store/miwzifnpn3lgzd6kvkcmz1i0hx7vvdfm-glibc-cross-i686-linux-gnu-2.33/lib/../lib/libc.so.6: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010001
BFD: warning: /gnu/store/miwzifnpn3lgzd6kvkcmz1i0hx7vvdfm-glibc-cross-i686-linux-gnu-2.33/lib/../lib/libc.so.6: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010002
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/gnu/store/miwzifnpn3lgzd6kvkcmz1i0hx7vvdfm-glibc-cross-i686-linux-gnu-2.33/lib/../lib/libthread_db.so.1".
^C
Program received signal SIGINT, Interrupt.
0xb7f86003 in __GI___pthread_mutex_lock (mutex=0xb7fff584 <_rtld_global+1348>)
    at ../nptl/pthread_mutex_lock.c:71
71  ../nptl/pthread_mutex_lock.c: No such file or directory.
--8<---------------cut here---------------end--------------->8---

Perhaps this problem will resolve with static linking, but I doubt it
given it has to do glibc.

If we could understand/resolve this issue, I'm confident the rest would
mostly be busywork, a couple evenings worth of work at most.

Thank you!

Maxim