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

--arch-name causing objdump problems #136

Open
moridinga opened this issue Apr 14, 2023 · 0 comments
Open

--arch-name causing objdump problems #136

moridinga opened this issue Apr 14, 2023 · 0 comments

Comments

@moridinga
Copy link

moridinga commented Apr 14, 2023

Working on an embedded project, targeting a Cortex-R52, and I've discovered that the fact that the --arch-name argument is passed to the llvm-objdump tool is causing disassembly to fundamentally misbehave (lots of <unknown> in the output as the disassembler won't decode certain opcodes). The executable is built using the armv7r-none-eabihf target triple, with target-cpu=cortex-r52 rustflag. If I run llvm-objdump -d directly against the output binary, the disassembly is perfect. If I run it with the additional --arch-name=arm (which is what the cargo-binutils is adding on when calling cargo objdump), then we see this problem. In other words, cargo-binutil's insistence on adding the --arch-name argument to the tool call is actually breaking it for this target. If this arg really is needed for some architectures, then I would request we make a similar exception for "arm" that we use for "thumb" and stop blindly passing this down to the tool invocation. It is not even clear why objdump is receiving this special treatment, while none of the other tools do.

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

1 participant