[llvm] [llvm-objdump] Add preliminary support for decoding binary files (PR #115667)

[Michael Clark via llvm-commits]

michaeljclark wrote:

> ```
> binutils - objdump -D -bbinary -mi386:x86-64 -Mintel test.bin
> this patch - llvm-objdump -d -b --triple x86_64 -Mintel test.bin
> ```
> 
> 
>     
>   
> 
> We can support `-b` with `binary` as the only value.
> 
> 
> In GNU objdump, we can specify `-bbinary`, `-bwasm` (wasm support only added around 2017?), and `-b elf64-x86-64`, but nobody seems to use `-belf*`.
> 
> 
> In llvm-project, we emulate the bfdname in at least two places:
> 
> 
> 
> * `llvm-objcopy -I binary` and `-O`
> 
> * `ld.lld --oformat=binary`.

this approach doesn't seem useful to me unless you implement `[-m machine|--architecture=machine]` from GNU binutils objdump which is why I removed the `-b` from this commit to eliminate a clash with GNU binutils objdump options. it seems `-m` in LLVM objdump is used for key value attributes and an ad-hoc `-macho` flag,

I call this a "pile on" where you gate addition of some feature due to a bunch of tangentially related issues to prevent incremental progress. I agree in concept to all of the other trival formatting, diagnostic and stylistic issues but until you either decide to stay clear of a clash or faithfully implement compatibility, then I don't see some intermediate point as being useful because the use cases will still fail. you sort of have to decide about `-m` for your stance to make sense.

in any case it is useful to leave the PR here because someone might want the function with the slightly different way of invoking it and pull the patch from the PR to their local tree, i.e. in a way that matches `--triple`. is there really a use case for WASM and ELF files without magic? or someone else may agree with the idea of broken partial compatibility and bend this patch to the demands of the maintainers.

https://github.com/llvm/llvm-project/pull/115667