6

I am trying to use objdump -d fileName on a s-rec file and it returns unknown architecture, however it recognizes fileName: file format srec

I looked at objdump --help and under supported targets srec and symbolsrec is listed.

I have tried

objdump -d -M srec myFile

objdump -d -m srec myFile

What is the best way to tackle this? Alternatives?

0siris
  • 61
  • 1
  • 1
  • 7

2 Answers2

5

SREC (aka S-Record) format is similar to raw binary - it contains just the byte values but, unlike ELF, no metadata about the CPU or OS used.

If you know the CPU used, you can pass it to objdump with the -m switch, e.g.:

objdump -m arm -D file.srec

Normally objdump should recognize the format automatically but you can also specify it explicitly with -b srec

Common CPUs used with these files include former Motorola series such as 6800/6812 (and derived Freescale's HC12), 68K/Coldfire but sometimes also others, e.g. 8051

Use objdump -i to list the processors and file formats supported by your build . You may need to make a custom binutils build to support your target CPU.

Igor Skochinsky
  • 36,553
  • 7
  • 65
  • 115
  • Thank you very much for your time, as a matter of fact my target is the Motorola series. Using objdump -i I don't see it listed, so I might have to go the custom build path... – 0siris May 23 '18 at 21:17
  • You're were using a .srec file not the binary file itself. Either use the binary or use suggested -b srec argument: Specify that the object-code format for the object files is bfdname. This option may not be necessary; objdump can automatically recognize many formats.

    In other words, you specify the format of the binary not the targeted architecture. S-Record or srec format: https://de.wikipedia.org/wiki/S-Record

     – kuch3n Jan 25 '24 at 17:41
0

In case this ends up being useful for anyone else, I had the same exact error, but it was in a cross-compilation project. My problem was that my CMake toolchain was erroneously setting CMAKE_OBJDUMP to /usr/bin/objdump instead of /usr/bin/arm-none-eabi-objdump. I fixed this by forcing my toolchain.cmake file to use /usr/bin/arm-none-eabi-objdump and /usr/bin/arm-none-eabi-objcopy, by adding these lines to my toolchain.cmake BEFORE any calls to find_program(...):

unset(CMAKE_OBJCOPY CACHE)
unset(CMAKE_OBJDUMP CACHE)

My CMake version is 3.16.3. I submitted a bug report for this here: https://gitlab.kitware.com/cmake/cmake/-/issues/20787

Mark Betters
  • 1
  • 1