You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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, withtarget-cpu=cortex-r52
rustflag. If I runllvm-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 callingcargo 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.The text was updated successfully, but these errors were encountered: