UBSAN might have caught this if we had a test that took this path but I need to confirm that. If so I could add some more as a smoke test of sorts, or just call help on every command if that's not going to take an age.

Do you have python enabled in the build? (https://lldb.llvm.org/resources/build.html#preliminaries)

Great, thanks for the explanation.

The last update didn't update the expected errors. I have done so in 9a93f95fce91fb4616cee0f307b564b253789282 and it's now passing. (I think it missed the bots since they don't build examples)

• Remove double AEK_NONE in arm1136jf-s test

• Remove unused includes

I assume that the signal displays without tag bits just like any other SEGV?

Have you looked at the how llvm YAML and JSON libraries handle (de)serialization? I was hoping that we could implement something similar to that...

For reference: https://github.com/google/googletest/blob/master/googletest/docs/advanced.md#using-a-predicate-formatter

@MarkMurrayARM Just updated to properly format the struct, the example in the summary is updated to what you'll get.

Added a custom formatter for the params struct.
(the default is to print the bytes of the struct)

• clang format

Change test params to a structure.

• replace const char* with StringRef in test params

I will add a better expect printer for the extension bitfields in a future change, just reorganising the tests here.

No problem, I'll have something for review in a few days.

Also the commit msg " Test case debugging output" should include which test cases, "target parser test cases" would do fine.

I see the idea to give some immediate improvement but I think there's more to be done to inform the user properly:

• Convert all of the runs of ASSERT_TRUE to individual tests using a test fixture (or two), for example [0]
• Creating a custom assertion message that includes the CPU name and the feature [1]
• Treating the features as a set, so we can say in one go "the features <list> are missing", instead of a one by one check
• Printing feature names when we do find a missing bit, you an ask the target parser for that

I realise it's a lot to review but if you have any initial comments on the usability that'd be great. My main point here was to make the if-else chain a bit "safer" and more easily extended. The parsing logic itself I did not change, to keep things clear (though I would like to improve it later).

Ping on -macho vs --macho question. Anyone else want to chime in?

Actually, more generally this warning shouldn't be printed directly to errs() in the lower-level code, but rather somehow fed back to the tool

• Double # for comment
• Add dashes to ELF header

For reference it's listed as --macho in https://llvm.org/docs/CommandGuide/llvm-objdump.html#cmdoption-llvm-objdump-macho. However that page is missing some of the "requires -macho" statements so could be a mistake.

• Added test for mcpu/mattr=help
• clang-format

This is a follow up to discussion on: https://reviews.llvm.org/D92217

I'll tackle the obvious bits first, thanks for the info.

• Document default constructor behaviour.

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

• Reformat GDBRemoteCommunicationServerPlatform.h to fix include order.

• Use auto for map find
• Document PortMap functions
• Remove unnecessary casts
• Move tests to Process/gdb-remote
• Cleanup Expected asserts

• Move PortMap into a class we can unittest
• Use llvm::Expected for GetNextAvailablePort

FYI my change to add the memory tagging flag (https://reviews.llvm.org/D87442) has landed so you will have some conflicts.

I'm going to stick with the test format as it is. No doubt I'll need to clean it up based on what future MTE tests look like.

• Use assertIn
• Cleanup Status/Error handling
• Refactor test so it runs once and we skip based on whether it returns a value or hits a breakpoint.
• Seperated exit codes for non MTE toolchain and non MTE target, for more specific skip reasons.

Updated the way the test works.

• If you build without MTE in the toolchain the binary just returns the magic failure number.
• If you do have an MTE toolchain but your target doesn't have MTE then it will also fail with the magic return code.

I hadn't considered using a unit test instead, I'll give that a go.

I have found existing tests that launch an lldb-server with specific arguments, using an existing lldb-server platform to do it.

For reference the argument was removed in: https://reviews.llvm.org/D90313

I presume these tests aren't commonly run or have been masked by the expected failures.