rust-embedded / cargo-binutils Goto Github PK

Seems to be caused by dependency chain "rustc-cfg 0.4.0" -> "failure 0.1.8" -> "backtrace 0.3.56" -> "object 0.23.0".

Usually a cargo command will automatically use the main binary if no binary or example is specified. This does not work for cargo-binutils and instead requires to specify the binary name which for a single binary crate is the project name and thus a bit clunky.

expected: I only get nm output when redirecting/piping cargo nm standard output
actual: rustc/cargo output is included as well:

❯ cargo nm | head -11
    Finished dev [unoptimized + debuginfo] target(s) in 0.00s
warning: unused variable: `unused`
  --> src/main.rs:17:9
   |
17 |     let unused = 4;
   |         ^^^^^^ help: if this is intentional, prefix it with an underscore: `_unused`
   |
   = note: `#[warn(unused_variables)]` on by default

warning: 1 warning emitted

0000000100031d88 s GCC_except_table0

As seen in #63 there're code paths which can lead to a panic! rather than an orderly error handling and reflection in an appropriate error code. Let's fix those!

Hi.
I believe you know the cause of this bug.

We used to xbuild our binary for an embedded system like:

cargo xbuild
cargo objdump -- -O binary inputfile outputfile

This now gives the error: llvm-objcopy: error: too many positional arguments
This started happening with v0.2.0. I suspect it is the switch to "cargo-metadata".

One fix we tried is to use a single "cargo objdump" command:

cargo objdump --bin inputbinary -- -O binary outputfile

However this way of invoking objdump builds the binary and without xbuild.

Is still possible to get the old behavior where there is no default --bin?

I installed the latest cargo-binutils but I am getting Failed to execute tool: nm when running cargo nm --bin main --release.

Software:

    System Software Overview:

      System Version: macOS 10.15.5 (19F101)
      Kernel Version: Darwin 19.5.0
      Boot Volume: Macintosh HD
      Boot Mode: Normal
      Secure Virtual Memory: Enabled
      System Integrity Protection: Disabled

cargo 1.44.0 (05d080faa 2020-05-06)

Default host: x86_64-apple-darwin
rustup home:  /Users/george/.rustup

installed toolchains
--------------------

stable-x86_64-apple-darwin (default)
nightly-x86_64-apple-darwin
1.38.0-x86_64-apple-darwin

active toolchain
----------------

stable-x86_64-apple-darwin (default)
rustc 1.44.0 (49cae5576 2020-06-01)

rustc-cfg includes failure, which includes backtrace, which includes backtrace-sys, which tries to compile libbacktrace from C source (https://github.com/rust-lang/backtrace-rs/blob/e745627050fde4161235c48fdc859ba4098a8a79/crates/backtrace-sys/build.rs#L23).

Dependency graph

cargo install cargo-binutils

    Updating crates.io index
  Installing cargo-binutils v0.1.6
   Compiling proc-macro2 v0.4.30
   Compiling unicode-xid v0.1.0
   Compiling libc v0.2.62
   Compiling cc v1.0.45
   Compiling syn v0.15.44
   Compiling proc-macro2 v1.0.3
   Compiling winapi-x86_64-pc-windows-gnu v0.4.0
   Compiling unicode-xid v0.2.0
   Compiling failure_derive v0.1.5
   Compiling winapi v0.3.8
   Compiling serde v1.0.100
   Compiling memchr v2.2.1
   Compiling syn v1.0.5
   Compiling rustc-demangle v0.1.16
   Compiling cfg-if v0.1.9
   Compiling bitflags v1.1.0
   Compiling unicode-width v0.1.6
   Compiling semver-parser v0.7.0
   Compiling regex v0.2.11
   Compiling lazy_static v1.4.0
   Compiling ucd-util v0.1.5
   Compiling strsim v0.8.0
   Compiling vec_map v0.8.1
   Compiling utf8-ranges v1.0.4
   Compiling textwrap v0.11.0
   Compiling semver v0.9.0
   Compiling thread_local v0.3.6
   Compiling regex-syntax v0.5.6
   Compiling backtrace-sys v0.1.31
   Compiling rustc_version v0.2.3
   Compiling quote v0.6.13
   Compiling quote v1.0.2
   Compiling aho-corasick v0.6.10
error: failed to run custom build command for `backtrace-sys v0.1.31`

Caused by:
  process didn't exit successfully: `C:\Users\USER\AppData\Local\Temp\cargo-installGpuluj\release\build\backtrace-sys-a9436706a9cb41a7\build-script-build` (exit code: 1)
--- stdout
cargo:rustc-cfg=rbt
TARGET = Some("x86_64-pc-windows-gnu")
OPT_LEVEL = Some("3")
HOST = Some("x86_64-pc-windows-gnu")
CC_x86_64-pc-windows-gnu = None
CC_x86_64_pc_windows_gnu = None
HOST_CC = None
CC = None
CFLAGS_x86_64-pc-windows-gnu = None
CFLAGS_x86_64_pc_windows_gnu = None
HOST_CFLAGS = None
CFLAGS = None
CRATE_CC_NO_DEFAULTS = None
CARGO_CFG_TARGET_FEATURE = Some("fxsr,mmx,sse,sse2")
running: "gcc.exe" "-O3" "-ffunction-sections" "-fdata-sections" "-m64" "-I" "src/libbacktrace" "-I" "C:\\Users\\USER\\AppData\\Local\\Temp\\cargo-installGpuluj\\release\\build\\backtrace-sys-809663e299ff9da7\\out" "-fvisibility=hidden" "-DBACKTRACE_SUPPORTED=1" "-DBACKTRACE_USES_MALLOC=1" "-DBACKTRACE_SUPPORTS_THREADS=0" "-DBACKTRACE_SUPPORTS_DATA=0" "-DHAVE_DL_ITERATE_PHDR=1" "-D_GNU_SOURCE=1" "-D_LARGE_FILES=1" "-Dbacktrace_full=__rbt_backtrace_full" "-Dbacktrace_dwarf_add=__rbt_backtrace_dwarf_add" "-Dbacktrace_initialize=__rbt_backtrace_initialize" "-Dbacktrace_pcinfo=__rbt_backtrace_pcinfo" "-Dbacktrace_syminfo=__rbt_backtrace_syminfo" "-Dbacktrace_get_view=__rbt_backtrace_get_view" "-Dbacktrace_release_view=__rbt_backtrace_release_view" "-Dbacktrace_alloc=__rbt_backtrace_alloc" "-Dbacktrace_free=__rbt_backtrace_free" "-Dbacktrace_vector_finish=__rbt_backtrace_vector_finish" "-Dbacktrace_vector_grow=__rbt_backtrace_vector_grow" "-Dbacktrace_vector_release=__rbt_backtrace_vector_release" "-Dbacktrace_close=__rbt_backtrace_close" "-Dbacktrace_open=__rbt_backtrace_open" "-Dbacktrace_print=__rbt_backtrace_print" "-Dbacktrace_simple=__rbt_backtrace_simple" "-Dbacktrace_qsort=__rbt_backtrace_qsort" "-Dbacktrace_create_state=__rbt_backtrace_create_state" "-Dbacktrace_uncompress_zdebug=__rbt_backtrace_uncompress_zdebug" "-Dmacho_get_view=__rbt_macho_get_view" "-Dmacho_symbol_type_relevant=__rbt_macho_symbol_type_relevant" "-Dmacho_get_commands=__rbt_macho_get_commands" "-Dmacho_try_dsym=__rbt_macho_try_dsym" "-Dmacho_try_dwarf=__rbt_macho_try_dwarf" "-Dmacho_get_addr_range=__rbt_macho_get_addr_range" "-Dmacho_get_uuid=__rbt_macho_get_uuid" "-Dmacho_add=__rbt_macho_add" "-Dmacho_add_symtab=__rbt_macho_add_symtab" "-Dmacho_file_to_host_u64=__rbt_macho_file_to_host_u64" "-Dmacho_file_to_host_u32=__rbt_macho_file_to_host_u32" "-Dmacho_file_to_host_u16=__rbt_macho_file_to_host_u16" "-o" "C:\\Users\\USER\\AppData\\Local\\Temp\\cargo-installGpuluj\\release\\build\\backtrace-sys-809663e299ff9da7\\out\\src/libbacktrace\\alloc.o" "-c" "src/libbacktrace/alloc.c"

--- stderr


error occurred: Failed to find tool. Is `gcc.exe` installed? (see https://github.com/alexcrichton/cc-rs#compile-time-requirements for help)



warning: build failed, waiting for other jobs to finish...
error: failed to compile `cargo-binutils v0.1.6`, intermediate artifacts can be found at `C:\Users\USER\AppData\Local\Temp\cargo-installGpuluj`

Caused by:
  build failed

here for example the output of cargo strip --lib minigrep --release:

thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /home/ido/.cargo/registry/src/github.com-1ecc6299db9ec823/car
go-binutils-0.2.0/src/lib.rs:232:24
stack backtrace:
   0:     0x7fe44b5bda44 - backtrace::backtrace::libunwind::trace::h90669f559fb267f0
                               at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/libunwind.rs:88
   1:     0x7fe44b5bda44 - backtrace::backtrace::trace_unsynchronized::hffde4e353d8f2f9a
                               at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/mod.rs:66
   2:     0x7fe44b5bda44 - std::sys_common::backtrace::_print_fmt::heaf44068b7eaaa6a
                               at src/libstd/sys_common/backtrace.rs:77
   3:     0x7fe44b5bda44 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h88671019cf081de2
                               at src/libstd/sys_common/backtrace.rs:59
   4:     0x7fe44b5df99c - core::fmt::write::h4e6a29ee6319c9fd
                               at src/libcore/fmt/mod.rs:1052
   5:     0x7fe44b5ba857 - std::io::Write::write_fmt::hf06b1c86d898d7d6
                               at src/libstd/io/mod.rs:1426
   6:     0x7fe44b5bfb25 - std::sys_common::backtrace::_print::h404ff5f2b50cae09
                               at src/libstd/sys_common/backtrace.rs:62
   7:     0x7fe44b5bfb25 - std::sys_common::backtrace::print::hcc4377f1f882322e
                               at src/libstd/sys_common/backtrace.rs:49
   8:     0x7fe44b5bfb25 - std::panicking::default_hook::{{closure}}::hc172eff6f35b7f39
                               at src/libstd/panicking.rs:204
   9:     0x7fe44b5bf811 - std::panicking::default_hook::h7a68887d113f8029
                               at src/libstd/panicking.rs:224
  10:     0x7fe44b5c012a - std::panicking::rust_panic_with_hook::hb7ad5693188bdb00
                               at src/libstd/panicking.rs:472
  11:     0x7fe44b5bfd10 - rust_begin_unwind
                               at src/libstd/panicking.rs:380
  12:     0x7fe44b5de4b1 - core::panicking::panic_fmt::hb1f3e14b86a3520c
                               at src/libcore/panicking.rs:85
  13:     0x7fe44b5de3fd - core::panicking::panic::hcdc9f0ba8d71d265
                               at src/libcore/panicking.rs:52
  14:     0x7fe44b43d04e - cargo_binutils::run::h139278197bcb7147
  15:     0x7fe44b434cb1 - cargo_strip::main::h70ef9e58a732eee1
  16:     0x7fe44b434e63 - std::rt::lang_start::{{closure}}::hea9b0dbe894299c8
  17:     0x7fe44b5bfbf3 - std::rt::lang_start_internal::{{closure}}::hb26e39676675046f
                               at src/libstd/rt.rs:52
  18:     0x7fe44b5bfbf3 - std::panicking::try::do_call::he4701ab6e48d80c0
                               at src/libstd/panicking.rs:305
  19:     0x7fe44b5c6a57 - __rust_maybe_catch_panic
                               at src/libpanic_unwind/lib.rs:86
  20:     0x7fe44b5c05d0 - std::panicking::try::hd3de25f3cb7024b8
                               at src/libstd/panicking.rs:281
  21:     0x7fe44b5c05d0 - std::panic::catch_unwind::h86c02743a24e3d92
                               at src/libstd/panic.rs:394
  22:     0x7fe44b5c05d0 - std::rt::lang_start_internal::h9cf8802361ad86c2
                               at src/libstd/rt.rs:51
  23:     0x7fe44b434d92 - main
  24:     0x7fe44ac21b97 - __libc_start_main
  25:     0x7fe44b4349ea - _start
  26:                0x0 - <unknown>

it panics for each binutil command I tried (strip, objdump, objcopy, and readobj).
occured on multiple projects.

After a while I figured out that running the commands without --lib (aka cargo strip minigrep --release) works as expected.

Currently cargo-profdata is the only cargo command that doesn't require a build.
Removing this would mean all cargo commands would require a build target and thus simplify the code as well as making the tool usage more consistent rust-$tool for direct tool usage and no builds, cargo-$tool for tools that utilize a cargo target.

I looked at this crate to address a problem with nasm-rs and windows, but sadly llvm-as isn't provided.

This issue is about improving the UI of the cargo-profdata subcommand to make it feel more
integrated with Cargo.

I have no experience with profiling so I have no suggestion for this subcommand. But the other
UI issues may provide some ideas.

cc @whitequark

STR

$ cargo new --lib foo && cd $_

$ cat >src/lib.rs <<'EOF'
#![no_std]
#[no_mangle]
pub fn foo(x: u32, y: u32) -> u32 {
    x + y
}
EOF

$ cargo objdump --lib --release --target armebv7r-none-eabi -- -d
/home/japaric/tmp/foo/target/armebv7r-none-eabi/release/libfoo.rlib(foo-5c3d4a3cd43899d6.foo.axz7xdhy-cgu.0.rcgu.o):    file format ELF32-arm-big

Disassembly of section .text.foo:
foo:
       0:       e0 81 00 00     andeq   r8, r0, r0, ror #3
       4:       e1 2f ff 1e     cdpne   p15, #15, c2, c15, c1, #7

Compare the output to the output of GNU objdump

$ arm-none-eabi-objdump -d target/armebv7r-none-eabi/release/libfoo.rlib
foo-5c3d4a3cd43899d6.foo.axz7xdhy-cgu.0.rcgu.o:     file format elf32-bigarm

Disassembly of section .text.foo:

00000000 <foo>:
   0:   e0810000        add     r0, r1, r0
   4:   e12fff1e        bx      lr

This is a bug in llvm-objdump. Reported as https://bugs.llvm.org/show_bug.cgi?id=38721

Meta

I used cargo-binutils v0.1.2 (currently unreleased) and tomorrow's nightly so I can't include sensible version information atm.

cc @paoloteti

Currently rust-lld is exposed as rust-ld, is there any particular reason for this?

My use case:
I noticed some odd behaviour when compiling for wasm in combination with -Z build-std, it needed additional help with -C linker-flavor=wasm-ld because of the name change.

I already found a solution for my use case, so this is rather a question than anything else.

I switched a project of mine from stable Rust to nightly Rust recently, and it was very confusing when later I noticed cargo objcopy wasn't working. The error is:

Failed to execute tool: objcopy
The system cannot find the file specified. (os error 2)

I'd also renamed my project in the meantime, so I got stuck down a tangent trying to figure out how renaming my project broke objcopy, assuming that it wasn't able to find the build output, rather than objcopy itself. It'd be nice if it reminded the user to ensure llvm-tools-preview is present on the current toolchain.

I have executed the following commands, both on Windows 10 and on Rasbian 10. All of them produce an empty file. Is this a bug or am I doing something wrong?

cargo objcopy --release --target thumbv7em-none-eabihf --bin main -- -O binary asdf.bin
cargo objcopy --target thumbv7em-none-eabihf --bin main -- -O binary asdf.bin
cargo objcopy --release --target thumbv7em-none-eabihf -- -O binary asdf.bin
cargo objcopy --release --target thumbv7em-none-eabihf -- -O binary asdf.bin

My main.rs looks like this:

#![no_std]
#![no_main]

use panic_semihosting as _;

use cortex_m_rt::entry;
use nrf52840_hal::clocks::Clocks;
use nrf52840_hal::usbd::{UsbPeripheral, Usbd};
use nrf52840_pac::Peripherals;
use usb_device::device::{UsbDeviceBuilder, UsbVidPid};
use usbd_serial::{SerialPort, USB_CLASS_CDC};

#[entry]
fn main() -> ! {
    let periph = Peripherals::take().unwrap();
    let clocks = Clocks::new(periph.CLOCK);
    let clocks = clocks.enable_ext_hfosc();

    let usb_bus = Usbd::new(UsbPeripheral::new(periph.USBD, &clocks));
    let mut serial = SerialPort::new(&usb_bus);

    let mut usb_dev = UsbDeviceBuilder::new(&usb_bus, UsbVidPid(0x16c0, 0x27dd))
        .manufacturer("Fake company")
        .product("Serial port")
        .serial_number("TEST")
        .device_class(USB_CLASS_CDC)
        .max_packet_size_0(64) // (makes control transfers 8x faster)
        .build();

    loop {
        if !usb_dev.poll(&mut [&mut serial]) {
            continue;
        }

        let mut buf = [0u8; 64];

        match serial.read(&mut buf) {
            Ok(count) if count > 0 => {
                // Echo back in upper case
                for c in buf[0..count].iter_mut() {
                    if 0x61 <= *c && *c <= 0x7a {
                        *c &= !0x20;
                    }
                }

                let mut write_offset = 0;
                while write_offset < count {
                    match serial.write(&buf[write_offset..count]) {
                        Ok(len) if len > 0 => {
                            write_offset += len;
                        }
                        _ => {}
                    }
                }
            }
            _ => {}
        }
    }
}

I have confirmed that the compiled ELF binary does in fact exist and is not an empty file. cargo size also shows a size of 0.

Toolchain info:
cargo 1.57.0
stable compiler
llvm-tools-preview has been added as a rustup component

use this setting to find out where the build artifacts are. The precedence order is as follows:

• CARGO_TARGET_DIR (highest precedence)
• target-dir setting in .cargo/config
• Default path of ${workspace_root}/target.

Hi,

When running cargo size --release (cargo-binutils v0.3.0) on a fresh repository I get the following error:

error: Can only have one matching artifact but found several

However checking the target folders there is only one artifact (app in my case):

thumbv7em-none-eabihf/debug/deps/app-a3b7f7101f0da200.d
thumbv7em-none-eabihf/debug/deps/app-f6b81f508609ad5e.d
thumbv7em-none-eabihf/debug/deps/libapp-a3b7f7101f0da200.rmeta
thumbv7em-none-eabihf/debug/deps/libapp-f6b81f508609ad5e.rmeta
thumbv7em-none-eabihf/release/app
thumbv7em-none-eabihf/release/app.d
thumbv7em-none-eabihf/release/deps/app-1f4505e64d40502e.d
thumbv7em-none-eabihf/release/deps/app-8b955e72da6ee189
thumbv7em-none-eabihf/release/deps/app-8b955e72da6ee189.d
thumbv7em-none-eabihf/release/deps/libapp-1f4505e64d40502e.rlib
thumbv7em-none-eabihf/release/deps/libapp-1f4505e64d40502e.rmeta
thumbv7em-none-eabihf/release/libapp.d
thumbv7em-none-eabihf/release/libapp.rlib

What seems to be happening is that it does not realize it should look for the binary.
Running the following gives the expected result: cargo size --release --bin app
And I have the [[bin]] section in the Cargo.toml, which was working fine before (not sure which version of cargo-binutils).

$ rustup component add llvm-tools --toolchain nightly
$ cargo +nightly install cargo-binutils

$ cargo +nightly size
error: llvm-tools component is missing or empty. Install it with rustup component add llvm-tools

$ rustup component list --toolchain nightly | grep tools
llvm-tools-x86_64-pc-windows-msvc (installed)

Version:

$ rustc +nightly -vV
rustc 1.28.0-nightly (cd494c1f0 2018-06-27)
binary: rustc
commit-hash: cd494c1f0915da00a63c03454a96d504afe764ff
commit-date: 2018-06-27
host: x86_64-pc-windows-msvc
release: 1.28.0-nightly
LLVM version: 6.0

Hello!

I updated to the 0.2.0 version of the crate and objdump (on windows) says that there's an unknown option "-triple". This should be "--triple" and it has already been fixed on master.

Maybe it's time to do another release so that this is solved on the latest version?

cargo $tool --lib only supports rlibs at the moment. WASM projects use cdylibs so e.g. cargo objdump --lib fails:

$ tail Cargo.toml

[lib]
crate-type = ["cdylib"]

$ cat src/lib.rs

#![feature(panic_handler)]
#![no_std]

use core::panic::PanicInfo;

#[no_mangle]
#[inline(never)]
pub fn foo(x: f32) -> f32 {
    x * x
}

#[panic_handler]
fn panic(_info: &PanicInfo) -> ! {
    loop {}
}

$ cargo objdump --target wasm32-unknown-unknown --lib -- -d
/home/japaric/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-objdump: 'libfoo.rlib': No such file or directory

When using the cargo size command it is misinterpreting the .rodata section as .data. Or am I using it incorrectly?

cargo size output:

$ cargo size -- -B target/thumbv7em-none-eabihf/release/trustflight 
   text    data     bss     dec     hex filename
    292     508       0     800     320 target/thumbv7em-none-eabihf/release/trustflight

arm-none-eabi-size output (correct):

$ arm-none-eabi-size -B target/thumbv7em-none-eabihf/release/trustflight
   text	   data	    bss	    dec	    hex	filename
    800	      0	      0	    800	    320	target/thumbv7em-none-eabihf/release/trustflight

Hi, I found that the cargo-readobj command proxies the llvm-readobj tool and uses --elf-output-style=GNU to make the output compatible with gnu-readelf. LLVM do provide a tool called llvm-readelf which is a symbolic link to llvm-readobj but is more compatible with gnu-readelf.

For example, gnu-readelf -s dumps symbols, llvm-readelf -s dumps symbols but llvm-readobj --elf-output-style -s dumps sections.

Do you have interest in adding cargo-readelf subcommand? I can give it a try.

user@host $ cat Cargo.toml
[package]
authors = ["[email protected]"]
edition = "2018"
name = "test_app"
version = "0.1.0"

[dependencies]
cortex-m = "0.5.7"
cortex-m-rt = "0.6.3"
cortex-m-semihosting = "0.3.1"
panic-halt = "0.2.0"

# Uncomment for the panic example.
panic-semihosting = "*"

# Uncomment for the allocator example.
# alloc-cortex-m = "0.3.5"

# Uncomment for the device example.
# [dependencies.stm32f30x]
# features = ["rt"]
# version = "0.7.1"

# this lets you use `cargo fix`!
[[bin]]
name = "test_app"
test = false
bench = false

[profile.release]
codegen-units = 1 # better optimizations
debug = true # symbols are nice and they don't increase the size on Flash
lto = true # better optimizations
user@host ~/Documents/rust_training/blank_app $ cargo +beta objdump --bin test_app -- -disassemble -no-show-raw-insn -print-imm-hex
    Finished dev [unoptimized + debuginfo] target(s) in 0.08s
C:\Users\jgp\.rustup\toolchains\beta-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\bin\llvm-objdump.exe: 'test_app.exe': no such file or directory

Is this a bug, or have I missed a step? If so, could we make it more obvious what's gone wrong?

Platform: Windows 10
Rust: rustc 1.30.0-beta.9 (a18eb4852 2018-09-30)

cargo objdump --lib --release -- -d
   Compiling myos v0.1.0 
    Finished release [optimized] target(s) in 0.23s

/home/haha/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-objdump: error: unknown argument '--arch-name'

And I straced the execution:

[pid 21330] execve("/home/haha/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-objdump", ["/home/haha/.rustup/toolchains/n"..., "--arch-name", "riscv64", "libmyos.rlib"], 0x7ffdd24f4340 /* 74 vars */ <unfinished ...

Find out llvm-objdump only accept param --arch-name=riscv64 instead of --arch-name riscv64.

Hi,

on nightly with "-Zmultitarget" or in config.toml "multitarget=true" allows to define one or more "--target" parameters.

Would be nice to have support for it here too.

Best regards,
TheAifam5

rust-lld can shadow the actual linker invoked by rustc, which is usually not the desired behavior, so it should be renamed.

In addition to that:

• rust-lld only looks in the sysroot of the default toolchain, which might not be the toolchain invoking it. This can result in nightly rustc using stable rust-lld, which is not a supported configuration.
• rust-lld also exits with a successful status code when it cannot find the actual rust-lld binary. This results in rustc thinking the linker succeeded, without actually producing any artifact. Cargo doesn't handle this case properly, and will try to run something that doesn't exist.

STR

$ cargo new --lib foo && cd $_

$ rustup target add powerpc-unknown-linux-gnu

$ cargo objdump --lib --target powerpc-unknown-linux-gnu --release -v -- -d
"/home/japaric/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/llvm-objdump" "-arch-name" "ppc" "libfoo.rlib" "-d"
/home/japaric/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/llvm-objdump: 'foo-c714e11050a7ef6e.foo.1whx4vim-cgu.0.rcgu.o': can't find target: error: invalid target 'ppc'.
.

libfoo.rlib(foo-c714e11050a7ef6e.foo.1whx4vim-cgu.0.rcgu.o):    file format ELF32-ppc

We are using the wrong -arch-name; it should be ppc32, not ppc.

This issue is about improving the UI of the cargo-nm subcommand to make it feel more integrated
with Cargo. Possible additions:

• cargo nm [--target $T] --example $E [--release] -- $ARGS. Builds $E for $T and then calls
  llvm-nm $ARGS target/$T/{debug,release}/examples/$E.

Thoughts? Suggestions?

I don't know where is a bug tracker for the llvm-tools, so let me place it here.

info: syncing channel updates for 'nightly-x86_64-pc-windows-msvc'
info: latest update on 2018-07-13, rust version 1.29.0-nightly (64f7de921 2018-07-12)
error: component 'llvm-tools' for 'x86_64-pc-windows-msvc' is unavailable for download

It's not about the "llvm-tools-preview" (NOTE The rustup component might be renamed to llvm-tools-preview to better reflect the lack of stability guarantees.), the component is completely missing:

$ rustup component list --toolchain nightly | grep llvm

$

I was reading https://docs.rust-embedded.org/book/unsorted/speed-vs-size.html and saw cargo size --bin app -- -A and thought i would run it on a example in one of my projects.

when i run cargo size --example icm_filter -- -A or cargo size --example icm_filter --features stm32f103 --release -- -A i get

Failed to execute tool: size
No such file or directory (os error 2)

while cargo run --example icm_filter --features stm32f103 --release does build/run.

I cant tell if its just my case that has a issue or if size does not work for examples..

Calling cargo-objcopy appears to output llvm-objcopy help message instead of the cargo-objcopy help message, afaik this should should require cargo objcopy -- -help?

STR

#![feature(panic_implementation)]
#![no_std]

use core::panic::PanicInfo;

#[no_mangle]
#[inline(never)]
pub fn foo(x: f32) -> f32 {
    x * x
}

#[panic_implementation]
fn panic(_info: &PanicInfo) -> ! {
    loop {}
}

$ cargo build --release --target wasm32-unknown-unknown

$ cargo objdump -- -d target/wasm32-unknown-unknown/release/*.wasm
error: invalid utf-8 sequence of 1 bytes from index 143

$ $(rustc --print sysroot)/lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-objdump -d target/wasm32-unknown-unknown/release/*.wasm

target/wasm32-unknown-unknown/release/bar.wasm: file format WASM

Disassembly of section CODE:
CODE:
       0:       02 02   block
       2:       00      br
       3:       0b      end_block
       4:       07 00   i32.catch       0
       6:       20 00   get_local       0
       8:       20 00   get_local       0
       a:       94      f32.mul
       b:       0b      end_block

I am a beginner of rust. When I run cargo objcopy --verbose --release --target=... -- ..., it looks like passing a strange argument to the objcopy command.

The execution log is the following.

# cargo objcopy --verbose --release --target=aarch64-unknown-none  -- --strip-all -O binary target/aarch64-unknown-none/release/kernel8 kernel8.img
"/usr/local/rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/cargo" "build" "--release" "--target" "aarch64-unknown-none" "--message-format=json"
    Finished release [optimized] target(s) in 0.01s
"rust-objcopy" "/workspace/rust-on-bare-metal-raspi3-samples/target/aarch64-unknown-none/release/kernel8" "--strip-all" "-O" "binary" "target/aarch64-unknown-none/release/kernel8" "kernel8.img"
/usr/local/rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-objcopy: error: too many positional arguments
#

I think "/workspace/rust-on-bare-metal-raspi3-samples/target/aarch64-unknown-none/release/kernel8" is a strange argument.

If more information is required to solve this problem, please tell me because I am not sure what information is important for debugging.

This issue is about improving the UI of the cargo-size subcommand to make it feel more integrated
with Cargo. Possible additions:

• cargo size [--target $T] --example $E [--release] -- $ARGS. Builds $E for $T and then calls
  llvm-size $ARGS target/$T/{debug,release}/examples/$E.

• cargo size [--target $T] --examples [--release] -- $ARGS. Builds all the examples and then
  calls llvm-size $ARGS target/$T/{debug,release}/examples/*.

Thoughts? Suggestions?

Right now, cargo nm for instance fails to work when used in a workspace. It errors out with

error: missing field `package`

STR

$ cat src/lib.rs

#![no_std]

#[no_mangle]
pub fn foo(x: u32, y: u32) -> u32 {
    x + y
}

$ cargo build --target riscv32imac-unknown-none-elf --release
$ cargo objdump --target riscv32imac-unknown-none-elf -v -- -d target/riscv32imac-unknown-none-elf/release/libfoo.rlib
"/home/japaric/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-objdump" "-triple" "riscv32imac-unknown-none-elf" "-d" "target/riscv32imac-unknown-none-elf/release/libfoo.rlib"

target/riscv32imac-unknown-none-elf/release/libfoo.rlib(foo-5f01dd28752961b9.foo0-d59093d565f158ef2f92ae2d0a10a47.rs.rcgu.o):     file format ELF32-riscv

/home/japaric/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-objdump: 'foo-5f01dd28752961b9.foo0-d59093d565f158ef2f92ae2d0a10a47.rs.rcgu.o': can't find target: : error: unable to get target for 'riscv32imac-unknown-none-elf', see --version and --triple.
.

The problem is that the triple passed to llvm-objdump is not a valid LLVM triple; riscv32imac is not a valid LLVM architecture name.

A solution to this problem would be to use pass -arch-name, instead of -triple, to llvm-objdump. The argument to pass would then have to be a valid LLVM architecture (see cargo objdump -- -version) so we would need to map the Rust architecture (see rustc --target $T --print cfg) into a LLVM architecture. We have to be careful with the thumbv* targets which have target_arch: "arm" but actually map to "thumb" LLVM architecture.

It looks like rustc-cfg is unmaintained or at least dormant. There are no commits since October 2018, and it's dependence on failure (despite a PR to fix it) makes cargo-audit fail for cargo-binutils and anything that depends on it.

It might be better to move this functionality into cargo-binutils itself. rustc-cfg/src/lib.rs contains less than 200 lines of code, many of which are comments. If the licenses are compatible, I think it would be beneficial to move this file/code into cargo-binutils so it can continue to receive maintenance and updates.

cargo objdump -- -d -no-show-raw-insn target/thumbv7m-none-eabi/debug/app is too long to write and redundant if you working on a binary crate. Let's have cargo-binutils infer the path of the executable. At the end we should be able to just write cargo objdump -- -d -no-show-raw-insn.

Here's what the logic should do (this may contain some errors / holes):

• If the user passed a path after -- use that and don't try to infer the path
• Else
  • Figure out where's the build directory; this will be the first part of our path
    • If CARGO_TARGET_DIR is set use that
    • If we are in a workspace use the $workspace_root/target
    • Else use $crate_root/target (XXX what about --manifest-path?)
  • Append the compilation target (e.g. thumbv7m-none-eabi) to the path.
  • If the user passed --release before -- use release as the next path segment; otherwise use debug as the next path segment
  • Figure out which executable we are dealing with
    • If the user passed --example $E before -- append examples/$E to the path.
    • else if the user passed --bin $B before -- append $B to the path
    • else if we are dealing with a binary crate (src/main.rs exists) append the crate name to the path
    • else (we are dealing with a library crate; src/main.rs is missing) error out (XXX we could check this earlier)
• Append our inferred path to tools_args

According to https://github.com/rust-embedded/debugonomicon/blob/master/src/overview.md, it should be possibly to generate a HEX from an ELF with cargo objcopy, similar to how a BIN can be generated, and in analogy with arm-none-eabi-objcopy. It seems that passing -O ihex however silently outputs an ELF.

Did this ever work? Should this work?

With version 0.2.0 the tools now use cargo-metadata and a more typical synopsis and interface to other cargo commands. That is, you can now call all tools directly without specifying the artifact you want to apply them too and they will automatically use the same artifact other cargo tools would use, i.e. if there's only one, that will be picked up by default. e.g. on a single binary crate just calling cargo size will do exactly what you expect it to do, same for cargo nm --release and all others.

I'm not sure when it was added, but llvm-ar is part of the llvm-tools-preview component as of at least rustup 1.18.3 (435397f48 2019-05-22)/rustc 1.37.0-nightly (5eeb567a2 2019-06-06).

 Directory of C:\Users\User\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\bin

07/06/2019  17:48    <DIR>          .
07/06/2019  17:48    <DIR>          ..
07/06/2019  17:48        13,695,488 llvm-ar.exe
07/06/2019  17:48        13,808,640 llvm-nm.exe
07/06/2019  17:48         3,406,336 llvm-objcopy.exe
07/06/2019  17:48        14,423,040 llvm-objdump.exe
07/06/2019  17:48         1,731,072 llvm-profdata.exe
07/06/2019  17:48         4,365,824 llvm-readobj.exe
07/06/2019  17:48         3,193,856 llvm-size.exe
07/06/2019  17:48         3,406,336 llvm-strip.exe
07/06/2019  12:52        43,632,640 rust-lld.exe

This issue is about improving the UI of the cargo-objdump subcommand to make it feel more
integrated with Cargo. Possible additions:

• cargo objdump [--target $T] --example $E [--release] -- $ARGS. Builds $E for $T and then
  calls llvm-objdump -disassemble $ARGS target/$T/{debug,release}/examples/$E. Perhaps pass
  -no-show-raw-insn by default.

Thoughts? Suggestions?

I'm having the following error:

error[E0599]: no method named `extend` found for type `&mut proc_macro::TokenStream` in the current scope
   --> /home/ceciliacarneiro/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.17/src/unstable.rs:213:21
    |
213 |                 tts.extend(
    |                     ^^^^^^

error[E0599]: no method named `extend` found for type `&mut proc_macro::TokenStream` in the current scope
   --> /home/ceciliacarneiro/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.17/src/unstable.rs:228:21
    |
228 |                 tts.extend(streams.into_iter().map(|stream| stream.unwrap_nightly()))
    |                     ^^^^^^

error: aborting due to 2 previous errors 

$ rustc -V rustc 1.30.0-nightly (73c78734b 2018-08-05)

As mentioned in: #86 (comment)

While experimenting with this I just noticed that the help generated by the CLI parser is off, but that can be addressed separately:

# cargo size --bin
error: The argument '--bin <NAME>' requires a value but none was supplied

USAGE:
    cargo-size <binary-name> --bin <NAME>

For more information try --help

The <binary-name> shouldn't exist in the output. Its currently used so that parsing is valid but its set to hidden so shouldn't be displayed, could be a bug in clap? more investigation needed.

This issue is about improving the UI of the cargo-objcopy subcommand to make it feel more
integrated with Cargo. Possible additions:

• cargo objcopy [--target $T] --example $E [--release] -- -O binary. Builds $E for $T and then
  calls llvm-objcopy -O binary target/$T/{debug,release}/examples/$E.

Thoughts? Suggestions?

cc @jcsoo

STR

Compare

$ llvm-objdump -arch-name=thumb -d app

app:    file format ELF32-arm-little

Disassembly of section .text:
Reset:
     400:       00 f0 1b f8     bl      #54
     404:       40  <unknown>
     405:       f2 00   lsls    r2, r6, #3
     407:       00 40   ands    r0, r0
     409:       f2 00   lsls    r2, r6, #3
     40b:       01 c2   stm     r2!, {r0}
     40d:       f2 00   lsls    r2, r6, #3
     40f:       00  <unknown>
     410:       c2  <unknown>
     411:       f2 00   lsls    r2, r6, #3
     413:       01 00   movs    r1, r0
     415:       f0 16   asrs    r0, r6, #27
     417:       f8 40   lsrs    r0, r7
     419:       f2 00   lsls    r2, r6, #3
     41b:       00 40   ands    r0, r0
     41d:       f2 5c   ldrb    r2, [r6, r3]
     41f:       41 40   eors    r1, r0
     421:       f2 00   lsls    r2, r6, #3
     423:       02 c2   stm     r2!, {r1}
     425:       f2 00   lsls    r2, r6, #3
     427:       00  <unknown>
     428:       c0  <unknown>
     429:       f2 00   lsls    r2, r6, #3
     42b:       01 c2   stm     r2!, {r0}
     42d:       f2 00   lsls    r2, r6, #3
     42f:       02 00   movs    r2, r0
     431:       f0 0e   lsrs    r0, r6, #27
     433:       f8 fe de fe     mrc2    p14, #7, apsr_nzcv, c8, c14, #6

UserHardFault_:
     436:       fe e7   b       #-4 <UserHardFault_>

UsageFault:
     438:       fe e7   b       #-4 <UsageFault>

__pre_init:
     43a:       70 47   bx      lr

HardFault:
     43c:       ef f3 08 80     mrs     r0, msp
     440:       ff f7 f9 ff     bl      #-14

__zero_bss:
     444:       00 22   movs    r2, #0
     446:       00 e0   b       #0 <__zero_bss+0x6>
     448:       04 c0   stm     r0!, {r2}
     44a:       88 42   cmp     r0, r1
     44c:       fc d3   blo     #-8 <__zero_bss+0x4>
     44e:       70 47   bx      lr

__init_data:
     450:       01 e0   b       #2 <__init_data+0x6>
     452:       08 c9   ldm     r1!, {r3}
     454:       08 c0   stm     r0!, {r3}
     456:       90 42   cmp     r0, r2
     458:       fb d3   blo     #-10 <__init_data+0x2>
     45a:       70 47   bx      lr

to:

$ llvm-objdump -triple=thumbv7m-none-eabi -d app

app:    file format ELF32-arm-little

Disassembly of section .text:
Reset:
     400:       00 f0 1b f8     bl      #54
     404:       40 f2 00 00     movw    r0, #0
     408:       40 f2 00 01     movw    r1, #0
     40c:       c2 f2 00 00     movt    r0, #8192
     410:       c2 f2 00 01     movt    r1, #8192
     414:       00 f0 16 f8     bl      #44
     418:       40 f2 00 00     movw    r0, #0
     41c:       40 f2 5c 41     movw    r1, #1116
     420:       40 f2 00 02     movw    r2, #0
     424:       c2 f2 00 00     movt    r0, #8192
     428:       c0 f2 00 01     movt    r1, #0
     42c:       c2 f2 00 02     movt    r2, #8192
     430:       00 f0 0e f8     bl      #28
     434:       fe de   trap

UserHardFault_:
     436:       fe e7   b       #-4 <UserHardFault_>

UsageFault:
     438:       fe e7   b       #-4 <UsageFault>

__pre_init:
     43a:       70 47   bx      lr

HardFault:
     43c:       ef f3 08 80     mrs     r0, msp
     440:       ff f7 f9 ff     bl      #-14

__zero_bss:
     444:       00 22   movs    r2, #0
     446:       00 e0   b       #0 <__zero_bss+0x6>
     448:       04 c0   stm     r0!, {r2}
     44a:       88 42   cmp     r0, r1
     44c:       fc d3   blo     #-8 <__zero_bss+0x4>
     44e:       70 47   bx      lr

__init_data:
     450:       01 e0   b       #2 <__init_data+0x6>
     452:       08 c9   ldm     r1!, {r3}
     454:       08 c0   stm     r0!, {r3}
     456:       90 42   cmp     r0, r2
     458:       fb d3   blo     #-10 <__init_data+0x2>
     45a:       70 47   bx      lr

Today we produce the former output. Let's tweak the logic to pass -triple to objdump when the target is thumb.

when building components of a larger project it is often useful to specify the manifest directory directly, particularly because we can't really do multi-target workspaces rust-lang/cargo#7004.

relates to actions-rs/cargo#86 which could mitigate this problem for github-actions.

(also seem to be seeing a similar issue to rust-lang/cargo#4866 when trying to build log for the wrong target when using a workspace but, not sure why that is)

When an error arises during cargo-metadata parsing, broken pipes and other nasties may appear, e.g.:

# cargo size
 Compiling cargo-binutils v0.2.0 (/Users/egger/OSS/cargo-binutils)
error: Can only have one matching artifact but found several=====>     ] 70/76: cargo-readobj(bin), rust-objcopy(bin), rust-ar(bin), rust-ld(bin), cargo-size(bin), rust-lld(bin)
Building [===================================================>     ] 70/76: cargo-readobj(bin), rust-objcopy(bin), rust-ar(bin), rust-ld(bin), cargothread 'main' panicked at 'failed printing to stdout: Broken pipe (os error 32)', src/libstd/io/stdio.rs:805:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace