The mcpu option was added in c9595620925499c0f33a5380158bad8cac46fda2.
It has never recognised "help" as far as I can tell.
Details
- Reviewers
jhenderson MaskRay
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
It works for me.
PS C:\Work\TempWork\> \llvm\build\Debug\bin\llvm-objdump --mcpu=help C:\Work\TempWork\bar.o -d C:\Work\TempWork\bar.o: file format elf64-x86-64 Available CPUs for this target: ...
However, you have to provide one of the "commands" or llvm-objdump will dump the help text. See https://llvm.org/docs/CommandGuide/llvm-objdump.html for details:
At least one of the following commands are required, and some commands can be combined with other commands
It would probably make sense to promote --mcpu=help specifically (i.e. not --mcpu=<some cpu>) to a "Command".
I figured it needed a file at least to know which target it should list cpus for, but now I see what I was doing wrong:
$ ./bin/llvm-objdump --mcpu=help /tmp/arm64.o -d /tmp/arm64.o: file format elf64-littleaarch64 Available CPUs for this target: a64fx - Select the a64fx processor. <...> Disassembly of section .init:
The cpus are printed to stderr and I just piped it into less to see the first bit easily so all I saw was the disassembly.
$ ./bin/llvm-objdump --mcpu=help /tmp/arm64.o -d 2>/dev/null /tmp/arm64.o: file format elf64-littleaarch64 Disassembly of section .init:
I see that --mattr=help also works this way. I assume that's because if you pass an invalid name it also prints to stderr,
but it's not an error, so you would still disassemble:
$ ./bin/llvm-objdump --mcpu=abcdef /tmp/arm64.o -d 1>/dev/null 'abcdef' is not a recognized processor for this target (ignoring processor) 'abcdef' is not a recognized processor for this target (ignoring processor) $ $? -bash: 0: command not found
(why it prints twice is another matter, --mattr doesn't)
Seems to me that:
- --mattr=help should be documented too
- The "--mcpu/attr=help" output should be on stdout (which is probably more tricky than I think it is)
- llvm-objdump shouldn't disassemble the file if you use those options (like llvm-objdump -d foo.o --help doesn't)
Which is probably easier said than done but does the logic make sense to you? At least I can do the first point quickly.
It would probably make sense to promote --mcpu=help specifically (i.e. not --mcpu=<some cpu>) to a "Command".
I assume doing this would help with the above?
Sounds like a possible bug, and worth either reporting, or investigating further and fixing, as I can't imagine it'll be too complex.
Seems to me that:
- --mattr=help should be documented too
Seems reasonable. If you do, make sure to add it to both help text and the user guide.
- The "--mcpu/attr=help" output should be on stdout (which is probably more tricky than I think it is)
Also seems reasonable (since --help does this). However, in this case, it would be good to get a few more opinions.
- llvm-objdump shouldn't disassemble the file if you use those options (like llvm-objdump -d foo.o --help doesn't)
I can see the logic behind this, although I'm slightly less certain about it. Again, other's opinions would be useful. If we do go down this route, it would make sense for --help + --mcpu=help to result in both bits being printed.
It would probably make sense to promote --mcpu=help specifically (i.e. not --mcpu=<some cpu>) to a "Command".
I assume doing this would help with the above?
For documentation purposes, it would definitely be a command, inasmuch as --help can be specified without other options with no problem (In llvm-objdump terminology, at least one "Command" (as opposed to "option") must be specified). I'm not sure off the top of my head the code semantics in this area. Even if we decide not to suppress other output for --mcpu=help (also --mattr=help), we should allow them to be specified without other options, I think, to avoid the sort of confusion you ran into.
clang-format not found in user's PATH; not linting file.