Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cargo nm can't find the path to existing binary #120

Open
wmstack opened this issue May 16, 2022 · 4 comments
Open

cargo nm can't find the path to existing binary #120

wmstack opened this issue May 16, 2022 · 4 comments

Comments

@wmstack
Copy link

wmstack commented May 16, 2022

As per the https://docs.rust-embedded.org/embedonomicon/smallest-no-std.html, I execute the following.

cargo nm -- target/thumbv7m-none-eabi/debug/deps/app-*.o | grep '[0-9]* [^N] '
/homeo/waleed/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-nm: error: target/thumbv7m-none-eabi/debug/deps/app-2fb83299481625ce.o: No such file or directory

The binary is in fact there, but llvm-nm doesn't notice.

rustc --version
rustc 1.60.0 (7737e0b5c 2022-04-04)

I installed llvm and with

llvm-nm target/thumbv7m-none-eabi/debug/deps/app-2fb83299481625ce.o
00000000 T rust_begin_unwind

it works, but the cargo nm command doesn't work.

@Emilgardis
Copy link
Member

Emilgardis commented May 16, 2022

the nm command sets the CWD to the parent of the executable/binary for the current crate, so try instead cargo nm -- deps/app-*.o

@wmstack
Copy link
Author

wmstack commented May 17, 2022

Still says the same error message

cargo nm -- deps/app-*.o
    Finished dev [unoptimized + debuginfo] target(s) in 0.00s
/home/waleed/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-nm: error: deps/app-*.o: No such file or directory

The error message is not helpful at all. It should at least put the full path it expects for the directory.

Edit: figured it out

cargo nm -- ./deps/app-2fb83299481625ce.o
Finished dev [unoptimized + debuginfo] target(s) in 0.00s

rt:
00000004 R RESET_VECTOR
00000008 T Reset

../../thumbv7m-none-eabi/debug/deps/app-2fb83299481625ce.o:
00000000 T rust_begin_unwind

It doesn't understand the wildcard. Probably because bash doesn't see the dependency, which is in a separate directory.

It also prints information that it wasn't supposed to print. It prints the information for the crate binary. Well I guess the more the better. As it currently stands, having useful information only printed with verbose is unacceptable Especially when the relatively recent book doesn't work as intended.

@Emilgardis
Copy link
Member

Emilgardis commented May 17, 2022

interesting, a glob works for me on windows. it's run as "C:\\path\\to\\target\\debug" "rust-nm" "test_cargobinutils.exe" "deps/libcfg_if-*.rlib" (using #121 to see cwd), the glob is kept and works in rust-nm

I wonder what has changed in rust-nm that makes this not work anymore. ping @rust-embedded/resources maybe the book needs to be updated to account for this?

@jannic
Copy link
Member

jannic commented Aug 16, 2022

I think the issue is twofold: First, @Emilgardis is right and target/thumbv7m-none-eabi/debug/ needs to be removed from the path as cargo nm enters that directory before calling llvm-nm.

But on the other hand, on unix, the glob is not resolved by the called command, but by the calling shell. And the shell doesn't know about that directory prefix, looks for deps/app-*.o from the current directory, and fails to resolve the glob.

Something like this could work (on unix) but is ugly:

cargo nm -- $(cd target/thumbv7m-none-eabi/debug/ && echo deps/app-*.o)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants