Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
ObjectFilePECOFF: Create a "container" section spanning the entire mo…
…dule image Summary: This is coming from the discussion in D55356 (the most interesting part happened on the mailing list, so it isn't reflected on the review page). In short the issue is that lldb assumes that all bytes of a module image in memory will be backed by a "section". This isn't the case for PECOFF files because the initial bytes of the module image will contain the file header, which does not correspond to any normal section in the file. In particular, this means it is not possible to implement GetBaseAddress function for PECOFF files, because that's supposed point to the first byte of that header. If my (limited) understanding of how PECOFF files work is correct, then the OS is expecded to load the entire module into one continuous chunk of memory. The address of that chunk (+/- ASLR) is given by the "image base" field in the COFF header, and it's size by "image size". All of the COFF sections are then loaded into this range. If that's true, then we can model this behavior in lldb by creating a "container" section to represent the entire module image, and then place other sections inside that. This would make be consistent with how MachO and ELF files are modelled (except that those can have multiple top-level containers as they can be loaded into multiple discontinuous chunks of memory). This change required a small number of fixups in the PDB plugins, which assumed a certain order of sections within the object file (which obivously changes now). I fix this by changing the lookup code to use section IDs (which are unchanged) instead of indexes. This has the nice benefit of removing spurious -1s in the plugins as the section IDs in the pdbs match the 1-based section IDs in the COFF plugin. Besides making the implementation of GetBaseAddress possible, this also improves the lookup of addresses in the gaps between the object file sections, which will now be correctly resolved as belonging to the object file. Reviewers: zturner, amccarth, stella.stamenova, clayborg, lemo Reviewed By: clayborg, lemo Subscribers: JDevlieghere, abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D56537 llvm-svn: 353916
- Loading branch information
Showing
6 changed files
with
94 additions
and
32 deletions.
There are no files selected for viewing
This file contains 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
This file contains 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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,70 @@ | ||
# RUN: yaml2obj %s > %t | ||
# RUN: lldb-test object-file %t | FileCheck %s | ||
|
||
|
||
# CHECK: Showing 1 sections | ||
# CHECK-NEXT: Index: 0 | ||
# CHECK-NEXT: ID: 0xffffffffffffffff | ||
# CHECK-NEXT: Name: | ||
# CHECK-NEXT: Type: container | ||
# CHECK-NEXT: Permissions: --- | ||
# CHECK-NEXT: Thread specific: no | ||
# CHECK-NEXT: VM address: 0x40000000 | ||
# CHECK-NEXT: VM size: 12288 | ||
# CHECK-NEXT: File size: 0 | ||
# CHECK-NEXT: Showing 2 subsections | ||
# CHECK-NEXT: Index: 0 | ||
# CHECK-NEXT: ID: 0x1 | ||
# CHECK-NEXT: Name: .text | ||
# CHECK-NEXT: Type: code | ||
# CHECK-NEXT: Permissions: --- | ||
# CHECK-NEXT: Thread specific: no | ||
# CHECK-NEXT: VM address: 0x40001000 | ||
# CHECK-NEXT: VM size: 64 | ||
# CHECK-NEXT: File size: 512 | ||
# CHECK-EMPTY: | ||
# CHECK-NEXT: Index: 1 | ||
# CHECK-NEXT: ID: 0x2 | ||
# CHECK-NEXT: Name: .data | ||
# CHECK-NEXT: Type: data | ||
# CHECK-NEXT: Permissions: --- | ||
# CHECK-NEXT: Thread specific: no | ||
# CHECK-NEXT: VM address: 0x40002000 | ||
# CHECK-NEXT: VM size: 64 | ||
# CHECK-NEXT: File size: 512 | ||
|
||
|
||
--- !COFF | ||
OptionalHeader: | ||
AddressOfEntryPoint: 4616 | ||
ImageBase: 1073741824 | ||
SectionAlignment: 4096 | ||
FileAlignment: 512 | ||
MajorOperatingSystemVersion: 6 | ||
MinorOperatingSystemVersion: 0 | ||
MajorImageVersion: 0 | ||
MinorImageVersion: 0 | ||
MajorSubsystemVersion: 6 | ||
MinorSubsystemVersion: 0 | ||
Subsystem: IMAGE_SUBSYSTEM_WINDOWS_CUI | ||
DLLCharacteristics: [ IMAGE_DLL_CHARACTERISTICS_HIGH_ENTROPY_VA, IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE, IMAGE_DLL_CHARACTERISTICS_NX_COMPAT, IMAGE_DLL_CHARACTERISTICS_TERMINAL_SERVER_AWARE ] | ||
SizeOfStackReserve: 1048576 | ||
SizeOfStackCommit: 4096 | ||
SizeOfHeapReserve: 1048576 | ||
SizeOfHeapCommit: 4096 | ||
header: | ||
Machine: IMAGE_FILE_MACHINE_AMD64 | ||
Characteristics: [ IMAGE_FILE_EXECUTABLE_IMAGE, IMAGE_FILE_LARGE_ADDRESS_AWARE ] | ||
sections: | ||
- Name: .text | ||
Characteristics: [ IMAGE_SCN_CNT_CODE, IMAGE_SCN_MEM_EXECUTE, IMAGE_SCN_MEM_READ ] | ||
VirtualAddress: 4096 | ||
VirtualSize: 64 | ||
SectionData: DEADBEEFBAADF00D | ||
- Name: .data | ||
Characteristics: [ IMAGE_SCN_CNT_INITIALIZED_DATA, IMAGE_SCN_MEM_READ ] | ||
VirtualAddress: 8192 | ||
VirtualSize: 64 | ||
SectionData: DEADBEEFBAADF00D | ||
symbols: [] | ||
... |
This file contains 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
This file contains 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
This file contains 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
This file contains 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