Proposal: SIGILL in btm

[Grommish]

Hi @ClementTsang !

This is going to be an odd request, which is why this is here and not in Issues.

Some background: I am currently working on integrating rust-lang into the OpenWrt build system. This involves creating new rust-lang tuples, building from source (rustup isn't an option), and other things that have nothing to do with you.

The problem is: I'm not a programmer.. I'm not a coder and I don't know rust-lang.

However, I am persistent.. I have rust-lang seemingly working, I've upstreamed the first of a handful of tuples, and I've moved on to testing.

I was looking for a rust project to use as a verifiable proof of concept and ran across bottom, especially since bottom appears to be actively maintained.

Backstory complete, here is the situation.

Keep in mind, I've had issues with mips64 as an arch under rust.

I've built bottom as an OpenWrt package, cross-compiled x86_64-unknown-linux-gnu/mips64-openwrt-linux-musl

btm: ELF 64-bit MSB executable, MIPS, MIPS64 rel2 version 1 (SYSV), statically linked, with debug_info, not stripped

When I run btm, it immediately throws a SIGILL

Again, I'm not a programmer and I don't know rust, but I can (generally) run gdb

Reading symbols from build_dir/target-mips64_octeonplus_64_musl/bottom-0.6.8/ipkg-mips64_octeonplus/bottom/usr/bin/btm...
warning: Unsupported auto-load script at offset 0 in section .debug_gdb_scripts
of file /home/grommish/openwrt/build_dir/target-mips64_octeonplus_64_musl/bottom-0.6.8/ipkg-mips64_octeonplus/bottom/usr/bin/btm.
Use `info auto-load python-scripts [REGEXP]' to list them.
0x0000000120007e00 in _start ()
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/grommish/openwrt/build_dir/target-mips64_octeonplus_64_musl/bottom-0.6.8/ipkg-mips64_octeonplus/bottom/usr/bin/btm

Program received signal SIGILL, Illegal instruction.
core::default::{impl#15}::default () at /home/grommish/openwrt/build_dir/hostpkg/rust-1.58.1/library/core/src/default.rs:179
179                 fn default() -> $t {
(gdb) bt
#0  core::default::{impl#15}::default () at /home/grommish/openwrt/build_dir/hostpkg/rust-1.58.1/library/core/src/default.rs:179
#1  0x0000000120142970 in core::array::{impl#56}::default<f32> () at /home/grommish/openwrt/build_dir/hostpkg/rust-1.58.1/library/core/src/array/mod.rs:383
#2  0x000000012007dad0 in bottom::canvas::{impl#2}::default () at src/canvas.rs:61
#3  0x00000001201d6358 in bottom::app::AppBuilder<((bottom::app::states::CpuState), (bottom::app::states::MemState), (bottom::app::states::NetState), (bottom::app::states::ProcState), (bottom::app::states::TempState), (bottom::app::states::DiskState), (bottom::app::states::BatteryState), (core::option::Option<bottom::app::states::BasicTableWidgetState>), (bottom::app::AppConfigFields), (std::collections::hash::map::HashMap<u64, bottom::app::layout_manager::BottomWidget, std::collections::hash::map::RandomState>), (bottom::app::layout_manager::BottomWidget), (bottom::app::layout_manager::UsedWidgets), (bottom::app::DataFilters), (bottom::options::Config), (core::option::Option<std::path::PathBuf>))>::build (self=...) at src/app.rs:86
#4  0x000000012028e33c in bottom::options::build_app (matches=0xffffff7f30, config=0xffffff8068, widget_layout=0xffffff94d0, default_widget_id=7, default_widget_type_option=0xffffff94f4, config_path=...)
    at src/options.rs:502
#5  0x0000000120017f28 in btm::main () at src/bin/main.rs:47
(gdb) print $pc
$1 = (*mut fn ()) 0x1200f5250 <core::default::{impl#15}::default>
(gdb)

I don't know where this error actually is coming from. Is it an issue with the rust-lang toolchain I created, something with bottom because my use-case is so out there whatever it is was never considered, something else?

I'd like your help with it, if you're willing. Since i don't know rust, I have no idea, but you do. I'm not asking for help with the integration (unless you want to!), but help with the rust end of things would be fantastic.

Thoughts?

EDIT:

Block from /home/grommish/openwrt/build_dir/hostpkg/rust-1.58.1/library/core/src/default.rs

macro_rules! default_impl {
    ($t:ty, $v:expr, $doc:tt) => {
        #[stable(feature = "rust1", since = "1.0.0")]
        #[rustc_const_unstable(feature = "const_default_impls", issue = "87864")]
        impl const Default for $t {
            #[inline]
            #[doc = $doc]
            fn default() -> $t {
                $v
            }
        }
    };
}

[ClementTsang]

Sorry for the late response. Thank you for looking into this so much already!

If you're still looking to get this resolved, from some quick checking, this seems to be related to this issue: rust-lang/rust#37507 (with similar issues regarding OpenWRT).

Unfortunately I don't really know how much more I can help right now as I don't have any device similar to yours to try on my own.

[Grommish]

Hi! What I'm doing is working to create the rust-lang toolchain itself, which is then used to create rust-lang apps to be used on OpenWrt. The issue I'm having is validating the end product. The {very complex} project I was working with originally I'm having issues with and I went looking for an actively maintained package.

Would you be able to tell me what (or, how I can find it myself) what might be needed library and/or dependency wise? For example, I was having tui issues, which I am guessing was due to a lack of libncurses (and possibly other things). ncurses isn't installed by default on target devices. So, things like this.

If you aren't opposed to it (and again, why I put it here), I'd like to get your input on potential issues with btm that I run into. I can tell you that with full debugging, it's like a 100mb bin :D

If you don't have the time (or simply the desire!) I understand; Just let me know!

[ClementTsang]

tui

I don't think tui-rs (or rather, the backend I'm using, crossterm) relies on ncurses, but I'm not 100% sure there.

I'd like to get your input on potential issues with btm that I run into.

One that I can't really predict is whether any data collection will work at all. It might work, it might fail miserably. The libraries I use do not (officially) support your use case, and while some might return no data gracefully, some might also crash the program. I have no idea how they behave in non-supported environments. I would imagine the biggest problem might be things reliant on sensors.

I would also say it's better if you compile for musl, as then you kinda dodge a lot of glibc problems I've seen in the past with compilation.

Other than that, I'm not really sure what else might cause problems, quite frankly. I'm a bit out of my element, unfortunately, but I don't think bottom has any big dependencies for Linux.

---

If your goal is just to get some large Rust project working, from how I'm understanding it, I would honestly look at something like ripgrep first. This is a massively popular project and I would imagine very helpful for people, while also probably having less issues to contend with in terms of just getting it up and running, since bottom has a bunch of platform-specific code and internal crates that might cause some issues.

[Grommish]

Hi! Thanks for pointing me towards ripgrep. I have it up and running on my OpenWrt MIPS64 device, so at least part of the toolchain is working! 👍 I appreciate the tip!

As for rust-lang, I currently am a Tier 3 target, so nothing is said to work properly. At some point in the future, I'd like to come back to bottom and give it another try, because it LOOKED great and I'd like to get it working :)

Thanks again!

[Grommish]

As a follow up:

I've successfully gotten bottom to build and deploy to mip64-openwrt-linux-musl device..

Thanks for your patience and for the project that allowed me to test!