- User Since
- Sep 24 2018, 3:51 AM (120 w, 6 d)
Tue, Jan 12
Do you have python enabled in the build? (https://lldb.llvm.org/resources/build.html#preliminaries)
Thu, Jan 7
Tue, Jan 5
Tue, Dec 22
Great, thanks for the explanation.
Mon, Dec 21
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
Dec 18 2020
- 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...
Dec 17 2020
@MarkMurrayARM Just updated to properly format the struct, the example in the summary is updated to what you'll get.
Dec 16 2020
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.
Dec 15 2020
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 
- Creating a custom assertion message that includes the CPU name and the feature 
- 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
Dec 14 2020
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).
Dec 10 2020
Dec 9 2020
Ping on -macho vs --macho question. Anyone else want to chime in?
Dec 2 2020
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
Dec 1 2020
Nov 30 2020
- 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
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.
Nov 27 2020
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
Nov 26 2020
- 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
Nov 24 2020
- Move PortMap into a class we can unittest
- Use llvm::Expected for GetNextAvailablePort
Nov 20 2020
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.
Nov 19 2020
- 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.
Nov 18 2020
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.
Nov 17 2020
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.