[lldb] Add utility to create Mach-O corefile from YAML desc (#153911) #11339
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
) I've wanted a utility to create a corefile for test purposes given a bit of memory and regsters, for a while. I've written a few API tests over the years that needed exactly this capability -- we have several one-off Mach-O corefile creator utility in the API testsuite to do this. But it's a lot of boilerplate when you only want to specify some register contents and memory contents, to create an API test. This adds yaml2mach-core, a tool that should build on any system, takes a yaml description of register values for one or more threads, optionally memory values for one or more memory regions, and can take a list of UUIDs that will be added as LC_NOTE "load binary" metadata to the corefile so binaries can be loaded into virtual address space in a test scenario. The format of the yaml file looks like ``` cpu: armv7m addressable-bits: num-bits: 39 binaries: - name: debug-binary.development uuid: 67942352-5857-3D3D-90CB-A3F80BA67B04 virtual-address: 0xfffffff01840c000 threads: - regsets: - flavor: gpr registers: [{name: sp, value: 0x2000fe70}, {name: r7, value: 0x2000fe80}, {name: pc, value: 0x0020392c}, {name: lr, value: 0x0020392d}] memory-regions: # stack memory - addr: 0x2000fe70 UInt32: [ 0x0000002a, 0x20010e58, 0x00203923, 0x00000001, 0x2000fe88, 0x00203911, 0x2000ffdc, 0xfffffff9 ] # instructions of a function - addr: 0x203910 UInt8: [ 0xf8, 0xb5, 0x04, 0xaf, 0x06, 0x4c, 0x07, 0x49, 0x74, 0xf0, 0x2e, 0xf8, 0x01, 0xac, 0x74, 0xf0 ] ``` and that's all that is needed to specify a corefile where four register values are specified (the others will be set to 0), and two memory regions will be emitted. The memory can be specified as an array of UInt8, UInt32, or UInt64, I anticipate that some of these corefiles may have stack values constructed manually and it may be simpler for a human to write them in a particular grouping of values. I needed this utility for an upcoming patch for ARM Cortex-M processors, to create a test for the change. I took the opportunity to remove two of the "trivial mach-o corefile" creator utilities I've written in the past, which also restricted the tests to only run on Darwin systems because I was using the system headers for Mach-O constant values. rdar://110663219 (cherry picked from commit a0c2d6e)
A couple of the ubuntu CI bots failed to compile saying that MappingTraits was unqualified despite a `using llvm::yaml::MappingTraits` earlier in the file. For PR llvm#153911 (cherry picked from commit fffd6da)
Fixes a CI fail on llvm#153911 (cherry picked from commit eb0c977)
I changed two tests that were previously @skipUnlessDarwin to run on all systems, using yaml2macho-core. I'm seeing failures on these tests on the Windows bots. I'm skipping them on Windows for now to unblock the CI, while I try to understand if this is a yaml2macho-core bug, or an existing problem with lldb's macho corefile reading on windows bug. v. llvm#153911 (cherry picked from commit 53efe0a)
These two 32-bit macho corefile tests are still failing on the lldb-remote-linux-win bot, I'd expect the @skipIfWindows decorator to skip the tests there until I can debug this, but somehow because it's a remote windows execution it's not working. Change these tests back to skipUnlessDarwin until I can figure out whether it's yaml2macho-core or lldb's 32-bit mach-o corefile reader support on windows which is the problem. (cherry picked from commit 4c17749)
(cherry picked from commit e7572d7)
The two API tests I converted to use yaml2macho-core were failing on windows. I was writing the output corefile with fopen(filename, "w"), and it turns out there was some newline conversion happening on Windows if a linefeed character was present. Charles Zablit helped to identify the issue and confirm the fix. Re-enabling the two tests on all platforms. llvm#153911 (cherry picked from commit 693146d)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I've wanted a utility to create a corefile for test purposes given a bit
of memory and regsters, for a while. I've written a few API tests over
the years that needed exactly this capability -- we have several one-off
Mach-O corefile creator utility in the API testsuite to do this. But
it's a lot of boilerplate when you only want to specify some register
contents and memory contents, to create an API test.
This adds yaml2mach-core, a tool that should build on any system, takes
a yaml description of register values for one or more threads,
optionally memory values for one or more memory regions, and can take a
list of UUIDs that will be added as LC_NOTE "load binary" metadata to
the corefile so binaries can be loaded into virtual address space in a
test scenario.
The format of the yaml file looks like
and that's all that is needed to specify a corefile where four register
values are specified (the others will be set to 0), and two memory
regions will be emitted.
The memory can be specified as an array of UInt8, UInt32, or UInt64, I
anticipate that some of these corefiles may have stack values
constructed manually and it may be simpler for a human to write them in
a particular grouping of values.
I needed this utility for an upcoming patch for ARM Cortex-M processors,
to create a test for the change. I took the opportunity to remove two of
the "trivial mach-o corefile" creator utilities I've written in the
past, which also restricted the tests to only run on Darwin systems
because I was using the system headers for Mach-O constant values.
rdar://110663219