2017-06-13 02:16:32 +02:00
|
|
|
// Check that cvtres properly handles merging multiple .res files.
|
|
|
|
|
// The inputs were generated with the following commands, using the original Windows
|
|
|
|
|
// rc.exe:
|
|
|
|
|
// > rc /fo test_resource.res /nologo test_resource.rc
|
|
|
|
|
// > rc /fo languages.res /nologo languages.rc
|
|
|
|
|
// The object file we are comparing against was generated with this command using
|
|
|
|
|
// the original Windows cvtres.exe.
|
|
|
|
|
// > cvtres /machine:X86 /readonly /nologo /out:combined.obj.coff \
|
|
|
|
|
// languages.res test_resource.res
|
|
|
|
|
|
2017-06-13 20:17:36 +02:00
|
|
|
RUN: llvm-cvtres /verbose /out:%t %p/Inputs/languages.res %p/Inputs/test_resource.res
|
2019-05-01 07:27:20 +02:00
|
|
|
RUN: llvm-readobj --coff-resources --section-data %t | FileCheck %s
|
2017-06-13 02:16:32 +02:00
|
|
|
|
|
|
|
|
CHECK: Resources [
|
|
|
|
|
CHECK-NEXT: Total Number of Resources: 12
|
|
|
|
|
CHECK-DAG: Number of String Entries: 1
|
|
|
|
|
CHECK-NEXT: Number of ID Entries: 5
|
|
|
|
|
CHECK-NEXT: Type: STRINGARRAY [
|
|
|
|
|
CHECK-NEXT: Table Offset: 0x40
|
|
|
|
|
CHECK-NEXT: Number of String Entries: 1
|
|
|
|
|
CHECK-NEXT: Number of ID Entries: 0
|
|
|
|
|
CHECK-NEXT: Name: MYRESOURCE [
|
|
|
|
|
CHECK-NEXT: Table Offset: 0xE8
|
|
|
|
|
CHECK-NEXT: Number of String Entries: 0
|
|
|
|
|
CHECK-NEXT: Number of ID Entries: 1
|
|
|
|
|
CHECK-NEXT: Language: (ID 1033) [
|
|
|
|
|
CHECK-NEXT: Entry Offset: 0x1D8
|
|
|
|
|
CHECK-NEXT: Time/Date Stamp: 1970-01-01 00:00:00 (0x0)
|
|
|
|
|
CHECK-NEXT: Major Version: 0
|
|
|
|
|
CHECK-NEXT: Minor Version: 0
|
|
|
|
|
CHECK-NEXT: Characteristics: 0
|
2019-08-29 11:00:14 +02:00
|
|
|
CHECK-NEXT: Data [
|
|
|
|
|
CHECK-NEXT: DataRVA: 0x0
|
|
|
|
|
CHECK-NEXT: DataSize: 57
|
|
|
|
|
CHECK-NEXT: Codepage: 0
|
|
|
|
|
CHECK-NEXT: Reserved: 0
|
[COFF] Add a ResourceSectionRef method for getting resource contents
This allows llvm-readobj to print the contents of each resource
when printing resources from an object file or executable, like it
already does for plain .res files.
This requires providing the whole COFFObjectFile to ResourceSectionRef.
This supports both object files and executables. For executables,
the DataRVA field is used as is to look up the right section.
For object files, ideally we would need to complete linking of them
and fix up all relocations to know what the DataRVA field would end up
being. In practice, the only thing that makes sense for an RVA field
is an ADDR32NB relocation. Thus, find a relocation pointing at this
field, verify that it has the expected type, locate the symbol it
points at, look up the section the symbol points at, and read from the
right offset in that section.
This works both for GNU windres object files (which use one single
.rsrc section, with all relocations against the base of the .rsrc
section, with the original value of the DataRVA field being the
offset of the data from the beginning of the .rsrc section) and
cvtres object files (with two separate .rsrc$01 and .rsrc$02 sections,
and one symbol per data entry, with the original pre-relocated DataRVA
field being set to zero).
Differential Revision: https://reviews.llvm.org/D66820
llvm-svn: 370433
2019-08-30 08:55:49 +02:00
|
|
|
CHECK-NEXT: Data (
|
|
|
|
|
CHECK: )
|
2019-08-29 11:00:14 +02:00
|
|
|
CHECK-NEXT: ]
|
2017-06-13 02:16:32 +02:00
|
|
|
CHECK-NEXT: ]
|
|
|
|
|
CHECK-NEXT: ]
|
|
|
|
|
CHECK-NEXT: ]
|
2019-04-25 01:26:30 +02:00
|
|
|
CHECK-NEXT: Type: BITMAP (ID 2) [
|
2017-06-13 02:16:32 +02:00
|
|
|
CHECK-NEXT: Table Offset: 0x58
|
|
|
|
|
CHECK-NEXT: Number of String Entries: 2
|
|
|
|
|
CHECK-NEXT: Number of ID Entries: 0
|
|
|
|
|
CHECK-NEXT: Name: CURSOR [
|
|
|
|
|
CHECK-NEXT: Table Offset: 0x100
|
|
|
|
|
CHECK-NEXT: Number of String Entries: 0
|
|
|
|
|
CHECK-NEXT: Number of ID Entries: 1
|
|
|
|
|
CHECK-NEXT: Language: (ID 1033) [
|
|
|
|
|
CHECK-NEXT: Entry Offset: 0x1E8
|
|
|
|
|
CHECK-NEXT: Time/Date Stamp: 1970-01-01 00:00:00 (0x0)
|
|
|
|
|
CHECK-NEXT: Major Version: 0
|
|
|
|
|
CHECK-NEXT: Minor Version: 0
|
|
|
|
|
CHECK-NEXT: Characteristics: 0
|
2019-08-29 11:00:14 +02:00
|
|
|
CHECK-NEXT: Data [
|
|
|
|
|
CHECK-NEXT: DataRVA: 0x0
|
|
|
|
|
CHECK-NEXT: DataSize: 808
|
|
|
|
|
CHECK-NEXT: Codepage: 0
|
|
|
|
|
CHECK-NEXT: Reserved: 0
|
[COFF] Add a ResourceSectionRef method for getting resource contents
This allows llvm-readobj to print the contents of each resource
when printing resources from an object file or executable, like it
already does for plain .res files.
This requires providing the whole COFFObjectFile to ResourceSectionRef.
This supports both object files and executables. For executables,
the DataRVA field is used as is to look up the right section.
For object files, ideally we would need to complete linking of them
and fix up all relocations to know what the DataRVA field would end up
being. In practice, the only thing that makes sense for an RVA field
is an ADDR32NB relocation. Thus, find a relocation pointing at this
field, verify that it has the expected type, locate the symbol it
points at, look up the section the symbol points at, and read from the
right offset in that section.
This works both for GNU windres object files (which use one single
.rsrc section, with all relocations against the base of the .rsrc
section, with the original value of the DataRVA field being the
offset of the data from the beginning of the .rsrc section) and
cvtres object files (with two separate .rsrc$01 and .rsrc$02 sections,
and one symbol per data entry, with the original pre-relocated DataRVA
field being set to zero).
Differential Revision: https://reviews.llvm.org/D66820
llvm-svn: 370433
2019-08-30 08:55:49 +02:00
|
|
|
CHECK-NEXT: Data (
|
|
|
|
|
CHECK: )
|
2019-08-29 11:00:14 +02:00
|
|
|
CHECK-NEXT: ]
|
2017-06-13 02:16:32 +02:00
|
|
|
CHECK-NEXT: ]
|
|
|
|
|
CHECK-NEXT: ]
|
|
|
|
|
CHECK-NEXT: Name: OKAY [
|
|
|
|
|
CHECK-NEXT: Table Offset: 0x118
|
|
|
|
|
CHECK-NEXT: Number of String Entries: 0
|
|
|
|
|
CHECK-NEXT: Number of ID Entries: 1
|
|
|
|
|
CHECK-NEXT: Language: (ID 1033) [
|
|
|
|
|
CHECK-NEXT: Entry Offset: 0x1F8
|
|
|
|
|
CHECK-NEXT: Time/Date Stamp: 1970-01-01 00:00:00 (0x0)
|
|
|
|
|
CHECK-NEXT: Major Version: 0
|
|
|
|
|
CHECK-NEXT: Minor Version: 0
|
|
|
|
|
CHECK-NEXT: Characteristics: 0
|
2019-08-29 11:00:14 +02:00
|
|
|
CHECK-NEXT: Data [
|
|
|
|
|
CHECK-NEXT: DataRVA: 0x0
|
|
|
|
|
CHECK-NEXT: DataSize: 808
|
|
|
|
|
CHECK-NEXT: Codepage: 0
|
|
|
|
|
CHECK-NEXT: Reserved: 0
|
[COFF] Add a ResourceSectionRef method for getting resource contents
This allows llvm-readobj to print the contents of each resource
when printing resources from an object file or executable, like it
already does for plain .res files.
This requires providing the whole COFFObjectFile to ResourceSectionRef.
This supports both object files and executables. For executables,
the DataRVA field is used as is to look up the right section.
For object files, ideally we would need to complete linking of them
and fix up all relocations to know what the DataRVA field would end up
being. In practice, the only thing that makes sense for an RVA field
is an ADDR32NB relocation. Thus, find a relocation pointing at this
field, verify that it has the expected type, locate the symbol it
points at, look up the section the symbol points at, and read from the
right offset in that section.
This works both for GNU windres object files (which use one single
.rsrc section, with all relocations against the base of the .rsrc
section, with the original value of the DataRVA field being the
offset of the data from the beginning of the .rsrc section) and
cvtres object files (with two separate .rsrc$01 and .rsrc$02 sections,
and one symbol per data entry, with the original pre-relocated DataRVA
field being set to zero).
Differential Revision: https://reviews.llvm.org/D66820
llvm-svn: 370433
2019-08-30 08:55:49 +02:00
|
|
|
CHECK-NEXT: Data (
|
|
|
|
|
CHECK: )
|
2019-08-29 11:00:14 +02:00
|
|
|
CHECK-NEXT: ]
|
2017-06-13 02:16:32 +02:00
|
|
|
CHECK-NEXT: ]
|
|
|
|
|
CHECK-NEXT: ]
|
|
|
|
|
CHECK-NEXT: ]
|
2019-04-25 01:26:30 +02:00
|
|
|
CHECK-NEXT: Type: MENU (ID 4) [
|
2017-06-13 02:16:32 +02:00
|
|
|
CHECK-NEXT: Table Offset: 0x78
|
|
|
|
|
CHECK-NEXT: Number of String Entries: 1
|
|
|
|
|
CHECK-NEXT: Number of ID Entries: 1
|
|
|
|
|
CHECK-NEXT: Name: "EAT" [
|
|
|
|
|
CHECK-NEXT: Table Offset: 0x130
|
|
|
|
|
CHECK-NEXT: Number of String Entries: 0
|
|
|
|
|
CHECK-NEXT: Number of ID Entries: 1
|
|
|
|
|
CHECK-NEXT: Language: (ID 3081) [
|
|
|
|
|
CHECK-NEXT: Entry Offset: 0x208
|
|
|
|
|
CHECK-NEXT: Time/Date Stamp: 1970-01-01 00:00:00 (0x0)
|
|
|
|
|
CHECK-NEXT: Major Version: 0
|
|
|
|
|
CHECK-NEXT: Minor Version: 0
|
|
|
|
|
CHECK-NEXT: Characteristics: 0
|
2019-08-29 11:00:14 +02:00
|
|
|
CHECK-NEXT: Data [
|
|
|
|
|
CHECK-NEXT: DataRVA: 0x0
|
|
|
|
|
CHECK-NEXT: DataSize: 48
|
|
|
|
|
CHECK-NEXT: Codepage: 0
|
|
|
|
|
CHECK-NEXT: Reserved: 0
|
[COFF] Add a ResourceSectionRef method for getting resource contents
This allows llvm-readobj to print the contents of each resource
when printing resources from an object file or executable, like it
already does for plain .res files.
This requires providing the whole COFFObjectFile to ResourceSectionRef.
This supports both object files and executables. For executables,
the DataRVA field is used as is to look up the right section.
For object files, ideally we would need to complete linking of them
and fix up all relocations to know what the DataRVA field would end up
being. In practice, the only thing that makes sense for an RVA field
is an ADDR32NB relocation. Thus, find a relocation pointing at this
field, verify that it has the expected type, locate the symbol it
points at, look up the section the symbol points at, and read from the
right offset in that section.
This works both for GNU windres object files (which use one single
.rsrc section, with all relocations against the base of the .rsrc
section, with the original value of the DataRVA field being the
offset of the data from the beginning of the .rsrc section) and
cvtres object files (with two separate .rsrc$01 and .rsrc$02 sections,
and one symbol per data entry, with the original pre-relocated DataRVA
field being set to zero).
Differential Revision: https://reviews.llvm.org/D66820
llvm-svn: 370433
2019-08-30 08:55:49 +02:00
|
|
|
CHECK-NEXT: Data (
|
|
|
|
|
CHECK: )
|
2019-08-29 11:00:14 +02:00
|
|
|
CHECK-NEXT: ]
|
2017-06-13 02:16:32 +02:00
|
|
|
CHECK-NEXT: ]
|
|
|
|
|
CHECK-NEXT: ]
|
|
|
|
|
CHECK-NEXT: Name: (ID 14432) [
|
|
|
|
|
CHECK-NEXT: Table Offset: 0x148
|
|
|
|
|
CHECK-NEXT: Number of String Entries: 0
|
|
|
|
|
CHECK-NEXT: Number of ID Entries: 1
|
|
|
|
|
CHECK-NEXT: Language: (ID 2052) [
|
|
|
|
|
CHECK-NEXT: Entry Offset: 0x218
|
|
|
|
|
CHECK-NEXT: Time/Date Stamp: 1970-01-01 00:00:00 (0x0)
|
|
|
|
|
CHECK-NEXT: Major Version: 0
|
|
|
|
|
CHECK-NEXT: Minor Version: 0
|
|
|
|
|
CHECK-NEXT: Characteristics: 0
|
2019-08-29 11:00:14 +02:00
|
|
|
CHECK-NEXT: Data [
|
|
|
|
|
CHECK-NEXT: DataRVA: 0x0
|
|
|
|
|
CHECK-NEXT: DataSize: 46
|
|
|
|
|
CHECK-NEXT: Codepage: 0
|
|
|
|
|
CHECK-NEXT: Reserved: 0
|
[COFF] Add a ResourceSectionRef method for getting resource contents
This allows llvm-readobj to print the contents of each resource
when printing resources from an object file or executable, like it
already does for plain .res files.
This requires providing the whole COFFObjectFile to ResourceSectionRef.
This supports both object files and executables. For executables,
the DataRVA field is used as is to look up the right section.
For object files, ideally we would need to complete linking of them
and fix up all relocations to know what the DataRVA field would end up
being. In practice, the only thing that makes sense for an RVA field
is an ADDR32NB relocation. Thus, find a relocation pointing at this
field, verify that it has the expected type, locate the symbol it
points at, look up the section the symbol points at, and read from the
right offset in that section.
This works both for GNU windres object files (which use one single
.rsrc section, with all relocations against the base of the .rsrc
section, with the original value of the DataRVA field being the
offset of the data from the beginning of the .rsrc section) and
cvtres object files (with two separate .rsrc$01 and .rsrc$02 sections,
and one symbol per data entry, with the original pre-relocated DataRVA
field being set to zero).
Differential Revision: https://reviews.llvm.org/D66820
llvm-svn: 370433
2019-08-30 08:55:49 +02:00
|
|
|
CHECK-NEXT: Data (
|
|
|
|
|
CHECK: )
|
2019-08-29 11:00:14 +02:00
|
|
|
CHECK-NEXT: ]
|
2017-06-13 02:16:32 +02:00
|
|
|
CHECK-NEXT: ]
|
|
|
|
|
CHECK-NEXT: ]
|
|
|
|
|
CHECK-NEXT: ]
|
2019-04-25 01:26:30 +02:00
|
|
|
CHECK-NEXT: Type: DIALOG (ID 5) [
|
2017-06-13 02:16:32 +02:00
|
|
|
CHECK-NEXT: Table Offset: 0x98
|
|
|
|
|
CHECK-NEXT: Number of String Entries: 1
|
|
|
|
|
CHECK-NEXT: Number of ID Entries: 0
|
|
|
|
|
CHECK-NEXT: Name: TESTDIALOG [
|
|
|
|
|
CHECK-NEXT: Table Offset: 0x160
|
|
|
|
|
CHECK-NEXT: Number of String Entries: 0
|
|
|
|
|
CHECK-NEXT: Number of ID Entries: 1
|
|
|
|
|
CHECK-NEXT: Language: (ID 1033) [
|
|
|
|
|
CHECK-NEXT: Entry Offset: 0x228
|
|
|
|
|
CHECK-NEXT: Time/Date Stamp: 1970-01-01 00:00:00 (0x0)
|
|
|
|
|
CHECK-NEXT: Major Version: 0
|
|
|
|
|
CHECK-NEXT: Minor Version: 0
|
|
|
|
|
CHECK-NEXT: Characteristics: 0
|
2019-08-29 11:00:14 +02:00
|
|
|
CHECK-NEXT: Data [
|
|
|
|
|
CHECK-NEXT: DataRVA: 0x0
|
|
|
|
|
CHECK-NEXT: DataSize: 108
|
|
|
|
|
CHECK-NEXT: Codepage: 0
|
|
|
|
|
CHECK-NEXT: Reserved: 0
|
[COFF] Add a ResourceSectionRef method for getting resource contents
This allows llvm-readobj to print the contents of each resource
when printing resources from an object file or executable, like it
already does for plain .res files.
This requires providing the whole COFFObjectFile to ResourceSectionRef.
This supports both object files and executables. For executables,
the DataRVA field is used as is to look up the right section.
For object files, ideally we would need to complete linking of them
and fix up all relocations to know what the DataRVA field would end up
being. In practice, the only thing that makes sense for an RVA field
is an ADDR32NB relocation. Thus, find a relocation pointing at this
field, verify that it has the expected type, locate the symbol it
points at, look up the section the symbol points at, and read from the
right offset in that section.
This works both for GNU windres object files (which use one single
.rsrc section, with all relocations against the base of the .rsrc
section, with the original value of the DataRVA field being the
offset of the data from the beginning of the .rsrc section) and
cvtres object files (with two separate .rsrc$01 and .rsrc$02 sections,
and one symbol per data entry, with the original pre-relocated DataRVA
field being set to zero).
Differential Revision: https://reviews.llvm.org/D66820
llvm-svn: 370433
2019-08-30 08:55:49 +02:00
|
|
|
CHECK-NEXT: Data (
|
|
|
|
|
CHECK: )
|
2019-08-29 11:00:14 +02:00
|
|
|
CHECK-NEXT: ]
|
2017-06-13 02:16:32 +02:00
|
|
|
CHECK-NEXT: ]
|
|
|
|
|
CHECK-NEXT: ]
|
|
|
|
|
CHECK-NEXT: ]
|
2019-04-25 01:26:30 +02:00
|
|
|
CHECK-NEXT: Type: ACCELERATOR (ID 9) [
|
2017-06-13 02:16:32 +02:00
|
|
|
CHECK-NEXT: Table Offset: 0xB0
|
|
|
|
|
CHECK-NEXT: Number of String Entries: 1
|
|
|
|
|
CHECK-NEXT: Number of ID Entries: 1
|
|
|
|
|
CHECK-NEXT: Name: MYACCELERATORS [
|
|
|
|
|
CHECK-NEXT: Table Offset: 0x178
|
|
|
|
|
CHECK-NEXT: Number of String Entries: 0
|
|
|
|
|
CHECK-NEXT: Number of ID Entries: 2
|
|
|
|
|
CHECK-NEXT: Language: (ID 1033) [
|
|
|
|
|
CHECK-NEXT: Entry Offset: 0x238
|
|
|
|
|
CHECK-NEXT: Time/Date Stamp: 1970-01-01 00:00:00 (0x0)
|
|
|
|
|
CHECK-NEXT: Major Version: 0
|
|
|
|
|
CHECK-NEXT: Minor Version: 0
|
|
|
|
|
CHECK-NEXT: Characteristics: 0
|
2019-08-29 11:00:14 +02:00
|
|
|
CHECK-NEXT: Data [
|
|
|
|
|
CHECK-NEXT: DataRVA: 0x0
|
|
|
|
|
CHECK-NEXT: DataSize: 24
|
|
|
|
|
CHECK-NEXT: Codepage: 0
|
|
|
|
|
CHECK-NEXT: Reserved: 0
|
[COFF] Add a ResourceSectionRef method for getting resource contents
This allows llvm-readobj to print the contents of each resource
when printing resources from an object file or executable, like it
already does for plain .res files.
This requires providing the whole COFFObjectFile to ResourceSectionRef.
This supports both object files and executables. For executables,
the DataRVA field is used as is to look up the right section.
For object files, ideally we would need to complete linking of them
and fix up all relocations to know what the DataRVA field would end up
being. In practice, the only thing that makes sense for an RVA field
is an ADDR32NB relocation. Thus, find a relocation pointing at this
field, verify that it has the expected type, locate the symbol it
points at, look up the section the symbol points at, and read from the
right offset in that section.
This works both for GNU windres object files (which use one single
.rsrc section, with all relocations against the base of the .rsrc
section, with the original value of the DataRVA field being the
offset of the data from the beginning of the .rsrc section) and
cvtres object files (with two separate .rsrc$01 and .rsrc$02 sections,
and one symbol per data entry, with the original pre-relocated DataRVA
field being set to zero).
Differential Revision: https://reviews.llvm.org/D66820
llvm-svn: 370433
2019-08-30 08:55:49 +02:00
|
|
|
CHECK-NEXT: Data (
|
|
|
|
|
CHECK: )
|
2019-08-29 11:00:14 +02:00
|
|
|
CHECK-NEXT: ]
|
2017-06-13 02:16:32 +02:00
|
|
|
CHECK-NEXT: ]
|
|
|
|
|
CHECK-NEXT: Language: (ID 2052) [
|
|
|
|
|
CHECK-NEXT: Entry Offset: 0x248
|
|
|
|
|
CHECK-NEXT: Time/Date Stamp: 1970-01-01 00:00:00 (0x0)
|
|
|
|
|
CHECK-NEXT: Major Version: 0
|
|
|
|
|
CHECK-NEXT: Minor Version: 0
|
|
|
|
|
CHECK-NEXT: Characteristics: 0
|
2019-08-29 11:00:14 +02:00
|
|
|
CHECK-NEXT: Data [
|
|
|
|
|
CHECK-NEXT: DataRVA: 0x0
|
|
|
|
|
CHECK-NEXT: DataSize: 24
|
|
|
|
|
CHECK-NEXT: Codepage: 0
|
|
|
|
|
CHECK-NEXT: Reserved: 0
|
[COFF] Add a ResourceSectionRef method for getting resource contents
This allows llvm-readobj to print the contents of each resource
when printing resources from an object file or executable, like it
already does for plain .res files.
This requires providing the whole COFFObjectFile to ResourceSectionRef.
This supports both object files and executables. For executables,
the DataRVA field is used as is to look up the right section.
For object files, ideally we would need to complete linking of them
and fix up all relocations to know what the DataRVA field would end up
being. In practice, the only thing that makes sense for an RVA field
is an ADDR32NB relocation. Thus, find a relocation pointing at this
field, verify that it has the expected type, locate the symbol it
points at, look up the section the symbol points at, and read from the
right offset in that section.
This works both for GNU windres object files (which use one single
.rsrc section, with all relocations against the base of the .rsrc
section, with the original value of the DataRVA field being the
offset of the data from the beginning of the .rsrc section) and
cvtres object files (with two separate .rsrc$01 and .rsrc$02 sections,
and one symbol per data entry, with the original pre-relocated DataRVA
field being set to zero).
Differential Revision: https://reviews.llvm.org/D66820
llvm-svn: 370433
2019-08-30 08:55:49 +02:00
|
|
|
CHECK-NEXT: Data (
|
|
|
|
|
CHECK: )
|
2019-08-29 11:00:14 +02:00
|
|
|
CHECK-NEXT: ]
|
2017-06-13 02:16:32 +02:00
|
|
|
CHECK-NEXT: ]
|
|
|
|
|
CHECK-NEXT: ]
|
|
|
|
|
CHECK-NEXT: Name: (ID 12) [
|
|
|
|
|
CHECK-NEXT: Table Offset: 0x198
|
|
|
|
|
CHECK-NEXT: Number of String Entries: 0
|
|
|
|
|
CHECK-NEXT: Number of ID Entries: 1
|
|
|
|
|
CHECK-NEXT: Language: (ID 1033) [
|
|
|
|
|
CHECK-NEXT: Entry Offset: 0x258
|
|
|
|
|
CHECK-NEXT: Time/Date Stamp: 1970-01-01 00:00:00 (0x0)
|
|
|
|
|
CHECK-NEXT: Major Version: 0
|
|
|
|
|
CHECK-NEXT: Minor Version: 0
|
|
|
|
|
CHECK-NEXT: Characteristics: 0
|
2019-08-29 11:00:14 +02:00
|
|
|
CHECK-NEXT: Data [
|
|
|
|
|
CHECK-NEXT: DataRVA: 0x0
|
|
|
|
|
CHECK-NEXT: DataSize: 24
|
|
|
|
|
CHECK-NEXT: Codepage: 0
|
|
|
|
|
CHECK-NEXT: Reserved: 0
|
[COFF] Add a ResourceSectionRef method for getting resource contents
This allows llvm-readobj to print the contents of each resource
when printing resources from an object file or executable, like it
already does for plain .res files.
This requires providing the whole COFFObjectFile to ResourceSectionRef.
This supports both object files and executables. For executables,
the DataRVA field is used as is to look up the right section.
For object files, ideally we would need to complete linking of them
and fix up all relocations to know what the DataRVA field would end up
being. In practice, the only thing that makes sense for an RVA field
is an ADDR32NB relocation. Thus, find a relocation pointing at this
field, verify that it has the expected type, locate the symbol it
points at, look up the section the symbol points at, and read from the
right offset in that section.
This works both for GNU windres object files (which use one single
.rsrc section, with all relocations against the base of the .rsrc
section, with the original value of the DataRVA field being the
offset of the data from the beginning of the .rsrc section) and
cvtres object files (with two separate .rsrc$01 and .rsrc$02 sections,
and one symbol per data entry, with the original pre-relocated DataRVA
field being set to zero).
Differential Revision: https://reviews.llvm.org/D66820
llvm-svn: 370433
2019-08-30 08:55:49 +02:00
|
|
|
CHECK-NEXT: Data (
|
|
|
|
|
CHECK: )
|
2019-08-29 11:00:14 +02:00
|
|
|
CHECK-NEXT: ]
|
2017-06-13 02:16:32 +02:00
|
|
|
CHECK-NEXT: ]
|
|
|
|
|
CHECK-NEXT: ]
|
|
|
|
|
CHECK-NEXT: ]
|
2019-04-25 01:26:30 +02:00
|
|
|
CHECK-NEXT: Type: RCDATA (ID 10) [
|
2017-06-13 02:16:32 +02:00
|
|
|
CHECK-NEXT: Table Offset: 0xD0
|
|
|
|
|
CHECK-NEXT: Number of String Entries: 1
|
|
|
|
|
CHECK-NEXT: Number of ID Entries: 0
|
|
|
|
|
CHECK-NEXT: Name: RANDOMDAT [
|
|
|
|
|
CHECK-NEXT: Table Offset: 0x1B0
|
|
|
|
|
CHECK-NEXT: Number of String Entries: 0
|
|
|
|
|
CHECK-NEXT: Number of ID Entries: 3
|
|
|
|
|
CHECK-NEXT: Language: (ID 1033) [
|
|
|
|
|
CHECK-NEXT: Entry Offset: 0x268
|
|
|
|
|
CHECK-NEXT: Time/Date Stamp: 1970-01-01 00:00:00 (0x0)
|
|
|
|
|
CHECK-NEXT: Major Version: 0
|
|
|
|
|
CHECK-NEXT: Minor Version: 0
|
|
|
|
|
CHECK-NEXT: Characteristics: 0
|
2019-08-29 11:00:14 +02:00
|
|
|
CHECK-NEXT: Data [
|
|
|
|
|
CHECK-NEXT: DataRVA: 0x0
|
|
|
|
|
CHECK-NEXT: DataSize: 54
|
|
|
|
|
CHECK-NEXT: Codepage: 0
|
|
|
|
|
CHECK-NEXT: Reserved: 0
|
[COFF] Add a ResourceSectionRef method for getting resource contents
This allows llvm-readobj to print the contents of each resource
when printing resources from an object file or executable, like it
already does for plain .res files.
This requires providing the whole COFFObjectFile to ResourceSectionRef.
This supports both object files and executables. For executables,
the DataRVA field is used as is to look up the right section.
For object files, ideally we would need to complete linking of them
and fix up all relocations to know what the DataRVA field would end up
being. In practice, the only thing that makes sense for an RVA field
is an ADDR32NB relocation. Thus, find a relocation pointing at this
field, verify that it has the expected type, locate the symbol it
points at, look up the section the symbol points at, and read from the
right offset in that section.
This works both for GNU windres object files (which use one single
.rsrc section, with all relocations against the base of the .rsrc
section, with the original value of the DataRVA field being the
offset of the data from the beginning of the .rsrc section) and
cvtres object files (with two separate .rsrc$01 and .rsrc$02 sections,
and one symbol per data entry, with the original pre-relocated DataRVA
field being set to zero).
Differential Revision: https://reviews.llvm.org/D66820
llvm-svn: 370433
2019-08-30 08:55:49 +02:00
|
|
|
CHECK-NEXT: Data (
|
|
|
|
|
CHECK: )
|
2019-08-29 11:00:14 +02:00
|
|
|
CHECK-NEXT: ]
|
2017-06-13 02:16:32 +02:00
|
|
|
CHECK-NEXT: ]
|
|
|
|
|
CHECK-NEXT: Language: (ID 2052) [
|
|
|
|
|
CHECK-NEXT: Entry Offset: 0x278
|
|
|
|
|
CHECK-NEXT: Time/Date Stamp: 1970-01-01 00:00:00 (0x0)
|
|
|
|
|
CHECK-NEXT: Major Version: 0
|
|
|
|
|
CHECK-NEXT: Minor Version: 0
|
|
|
|
|
CHECK-NEXT: Characteristics: 0
|
2019-08-29 11:00:14 +02:00
|
|
|
CHECK-NEXT: Data [
|
|
|
|
|
CHECK-NEXT: DataRVA: 0x0
|
|
|
|
|
CHECK-NEXT: DataSize: 67
|
|
|
|
|
CHECK-NEXT: Codepage: 0
|
|
|
|
|
CHECK-NEXT: Reserved: 0
|
[COFF] Add a ResourceSectionRef method for getting resource contents
This allows llvm-readobj to print the contents of each resource
when printing resources from an object file or executable, like it
already does for plain .res files.
This requires providing the whole COFFObjectFile to ResourceSectionRef.
This supports both object files and executables. For executables,
the DataRVA field is used as is to look up the right section.
For object files, ideally we would need to complete linking of them
and fix up all relocations to know what the DataRVA field would end up
being. In practice, the only thing that makes sense for an RVA field
is an ADDR32NB relocation. Thus, find a relocation pointing at this
field, verify that it has the expected type, locate the symbol it
points at, look up the section the symbol points at, and read from the
right offset in that section.
This works both for GNU windres object files (which use one single
.rsrc section, with all relocations against the base of the .rsrc
section, with the original value of the DataRVA field being the
offset of the data from the beginning of the .rsrc section) and
cvtres object files (with two separate .rsrc$01 and .rsrc$02 sections,
and one symbol per data entry, with the original pre-relocated DataRVA
field being set to zero).
Differential Revision: https://reviews.llvm.org/D66820
llvm-svn: 370433
2019-08-30 08:55:49 +02:00
|
|
|
CHECK-NEXT: Data (
|
|
|
|
|
CHECK: )
|
2019-08-29 11:00:14 +02:00
|
|
|
CHECK-NEXT: ]
|
2017-06-13 02:16:32 +02:00
|
|
|
CHECK-NEXT: ]
|
|
|
|
|
CHECK-NEXT: Language: (ID 4103) [
|
|
|
|
|
CHECK-NEXT: Entry Offset: 0x288
|
|
|
|
|
CHECK-NEXT: Time/Date Stamp: 1970-01-01 00:00:00 (0x0)
|
|
|
|
|
CHECK-NEXT: Major Version: 0
|
|
|
|
|
CHECK-NEXT: Minor Version: 0
|
|
|
|
|
CHECK-NEXT: Characteristics: 0
|
2019-08-29 11:00:14 +02:00
|
|
|
CHECK-NEXT: Data [
|
|
|
|
|
CHECK-NEXT: DataRVA: 0x0
|
|
|
|
|
CHECK-NEXT: DataSize: 66
|
|
|
|
|
CHECK-NEXT: Codepage: 0
|
|
|
|
|
CHECK-NEXT: Reserved: 0
|
[COFF] Add a ResourceSectionRef method for getting resource contents
This allows llvm-readobj to print the contents of each resource
when printing resources from an object file or executable, like it
already does for plain .res files.
This requires providing the whole COFFObjectFile to ResourceSectionRef.
This supports both object files and executables. For executables,
the DataRVA field is used as is to look up the right section.
For object files, ideally we would need to complete linking of them
and fix up all relocations to know what the DataRVA field would end up
being. In practice, the only thing that makes sense for an RVA field
is an ADDR32NB relocation. Thus, find a relocation pointing at this
field, verify that it has the expected type, locate the symbol it
points at, look up the section the symbol points at, and read from the
right offset in that section.
This works both for GNU windres object files (which use one single
.rsrc section, with all relocations against the base of the .rsrc
section, with the original value of the DataRVA field being the
offset of the data from the beginning of the .rsrc section) and
cvtres object files (with two separate .rsrc$01 and .rsrc$02 sections,
and one symbol per data entry, with the original pre-relocated DataRVA
field being set to zero).
Differential Revision: https://reviews.llvm.org/D66820
llvm-svn: 370433
2019-08-30 08:55:49 +02:00
|
|
|
CHECK-NEXT: Data (
|
|
|
|
|
CHECK: )
|
2019-08-29 11:00:14 +02:00
|
|
|
CHECK-NEXT: ]
|
2017-06-13 02:16:32 +02:00
|
|
|
CHECK-NEXT: ]
|
|
|
|
|
CHECK-NEXT: ]
|
|
|
|
|
CHECK-NEXT: ]
|
|
|
|
|
CHECK-DAG: .rsrc$02 Data (
|
|
|
|
|
CHECK-NEXT: 0000: 74686973 20697320 61207261 6E646F6D |this is a random|
|
|
|
|
|
CHECK-NEXT: 0010: 20626974 206F6620 64617461 20746861 | bit of data tha|
|
|
|
|
|
CHECK-NEXT: 0020: 74206D65 616E7320 6E6F7468 696E6700 |t means nothing.|
|
|
|
|
|
CHECK-NEXT: 0030: A9230E14 F4F60000 7A686534 20736869 |.#......zhe4 shi|
|
|
|
|
|
CHECK-NEXT: 0040: 34207969 31676534 20737569 326A6931 |4 yi1ge4 sui2ji1|
|
|
|
|
|
CHECK-NEXT: 0050: 20646520 73687534 6A75342C 207A6865 | de shu4ju4, zhe|
|
|
|
|
|
CHECK-NEXT: 0060: 34207969 34776569 347A6865 20736865 |4 yi4wei4zhe she|
|
|
|
|
|
CHECK-NEXT: 0070: 6E326D65 00A9230E 14F4F600 00000000 |n2me..#.........|
|
|
|
|
|
CHECK-NEXT: 0080: 44696573 20697374 2065696E 207A7566 |Dies ist ein zuf|
|
|
|
|
|
CHECK-NEXT: 0090: C3A46C6C 69676573 20426974 20766F6E |..lliges Bit von|
|
|
|
|
|
CHECK-NEXT: 00A0: 20446174 656E2C20 64696520 6E696368 | Daten, die nich|
|
|
|
|
|
CHECK-NEXT: 00B0: 74732062 65646575 74657400 A9230E14 |ts bedeutet..#..|
|
|
|
|
|
CHECK-NEXT: 00C0: F4F60000 00000000 11000300 E7030000 |................|
|
|
|
|
|
CHECK-NEXT: 00D0: 0D004400 4C040000 82001200 BC010000 |..D.L...........|
|
|
|
|
|
CHECK-NEXT: 00E0: 11000300 E7030000 0D004400 4C040000 |..........D.L...|
|
|
|
|
|
CHECK-NEXT: 00F0: 82001200 BC010000 28000000 10000000 |........(.......|
|
|
|
|
|
CHECK-NEXT: 0100: 10000000 01001800 00000000 00030000 |................|
|
|
|
|
|
CHECK-NEXT: 0110: C40E0000 C40E0000 00000000 00000000 |................|
|
|
|
|
|
CHECK-NEXT: 0120: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 0130: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 0140: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 0150: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 0160: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 0170: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 0180: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 0190: FFFFFFFF FF7F7F7F 7C7C7C78 78787575 |........|||xxxuu|
|
|
|
|
|
CHECK-NEXT: 01A0: 75FFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |u...............|
|
|
|
|
|
CHECK-NEXT: 01B0: FFFFFFFF FFFFFFFF FFFFFFFF 979797FF |................|
|
|
|
|
|
CHECK-NEXT: 01C0: FFFFFFFF FF838383 AAAAAADB DBDB7979 |..............yy|
|
|
|
|
|
CHECK-NEXT: 01D0: 79757575 FFFFFFFF FFFFFFFF FFFFFFFF |yuuu............|
|
|
|
|
|
CHECK-NEXT: 01E0: FFFFFFFF FFFFFFFF FFFFFFFF 9C9C9C98 |................|
|
|
|
|
|
CHECK-NEXT: 01F0: 9898FFFF FF888888 DBDBDBB7 B7B77D7D |..............}}|
|
|
|
|
|
CHECK-NEXT: 0200: 7DFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |}...............|
|
|
|
|
|
CHECK-NEXT: 0210: FFFFFFFF FFFFFFFF FFFFFFFF A0A0A09C |................|
|
|
|
|
|
CHECK-NEXT: 0220: 9C9C9393 93ADADAD F2F2F284 84848181 |................|
|
|
|
|
|
CHECK-NEXT: 0230: 81FFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 0240: FFFFFFFF FFFFFFFF FFFFFFFF A4A4A4D7 |................|
|
|
|
|
|
CHECK-NEXT: 0250: D7D79D9D 9DD0D0D0 EEEEEE91 91918D8D |................|
|
|
|
|
|
CHECK-NEXT: 0260: 8DFFFFFF FFFFFF81 81817E7E 7EFFFFFF |..........~~~...|
|
|
|
|
|
CHECK-NEXT: 0270: FFFFFFFF FFFFFFFF FFFFFFFF A9A9A9F2 |................|
|
|
|
|
|
CHECK-NEXT: 0280: F2F2E5E5 E5E2E2E2 95959591 91918D8D |................|
|
|
|
|
|
CHECK-NEXT: 0290: 8D898989 868686FF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 02A0: FFFFFFFF FFFFFFFF FFFFFFFF ADADADF2 |................|
|
|
|
|
|
CHECK-NEXT: 02B0: F2F2E1E1 E1DFDFDF E7E7E7E4 E4E4BBBB |................|
|
|
|
|
|
CHECK-NEXT: 02C0: BB8E8E8E FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 02D0: FFFFFFFF FFFFFFFF FFFFFFFF B5B5B5F2 |................|
|
|
|
|
|
CHECK-NEXT: 02E0: F2F2E8E8 E8E7E7E7 EAEAEAC6 C6C69E9E |................|
|
|
|
|
|
CHECK-NEXT: 02F0: 9EFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 0300: FFFFFFFF FFFFFFFF FFFFFFFF B9B9B9F4 |................|
|
|
|
|
|
CHECK-NEXT: 0310: F4F4ECEC ECEDEDED CBCBCBA7 A7A7FFFF |................|
|
|
|
|
|
CHECK-NEXT: 0320: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 0330: FFFFFFFF FFFFFFFF FFFFFFFF BDBDBDF7 |................|
|
|
|
|
|
CHECK-NEXT: 0340: F7F7EFEF EFD0D0D0 AFAFAFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 0350: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 0360: FFFFFFFF FFFFFFFF FFFFFFFF C1C1C1F7 |................|
|
|
|
|
|
CHECK-NEXT: 0370: F7F7D5D5 D5B6B6B6 FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 0380: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 0390: FFFFFFFF FFFFFFFF FFFFFFFF C4C4C4D9 |................|
|
|
|
|
|
CHECK-NEXT: 03A0: D9D9BEBE BEFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 03B0: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 03C0: FFFFFFFF FFFFFFFF FFFFFFFF C8C8C8C5 |................|
|
|
|
|
|
CHECK-NEXT: 03D0: C5C5FFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 03E0: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 03F0: FFFFFFFF FFFFFFFF FFFFFFFF CBCBCBFF |................|
|
|
|
|
|
CHECK-NEXT: 0400: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 0410: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 0420: 28000000 10000000 10000000 01001800 |(...............|
|
|
|
|
|
CHECK-NEXT: 0430: 00000000 00030000 C40E0000 C40E0000 |................|
|
|
|
|
|
CHECK-NEXT: 0440: 00000000 00000000 FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 0450: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 0460: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 0470: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 0480: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 0490: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 04A0: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 04B0: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 04C0: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 04D0: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 04E0: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 04F0: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 0500: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 0510: FFFFFFFF A0E3A901 B31801B3 1801B318 |................|
|
|
|
|
|
CHECK-NEXT: 0520: 01B31801 B31801B3 1861D06F FFFFFFFF |.........a.o....|
|
|
|
|
|
CHECK-NEXT: 0530: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 0540: FFFFFFFF 01B31800 D7331CDB 49DBF9E2 |.........3..I...|
|
|
|
|
|
CHECK-NEXT: 0550: 9BEFAF00 D73300D7 3301B318 FFFFFFFF |.....3..3.......|
|
|
|
|
|
CHECK-NEXT: 0560: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 0570: FFFFFFFF 01B31800 DE55F6FE F9DBFAE7 |.........U......|
|
|
|
|
|
CHECK-NEXT: 0580: FEFFFE86 EFAE00DE 5501B318 FFFFFFFF |........U.......|
|
|
|
|
|
CHECK-NEXT: 0590: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 05A0: FFFFFFFF 01B31800 E676DBFB EC00E676 |.........v.....v|
|
|
|
|
|
CHECK-NEXT: 05B0: 57EFA5FB FFFD55EE A401B318 FFFFFFFF |W.....U.........|
|
|
|
|
|
CHECK-NEXT: 05C0: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 05D0: FFFFFFFF 01B31800 ED9800ED 9800ED98 |................|
|
|
|
|
|
CHECK-NEXT: 05E0: 00ED9887 F7CFFEFF FF01B318 FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 05F0: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 0600: FFFFFFFF 01B31800 F4BA00F4 BA00F4BA |................|
|
|
|
|
|
CHECK-NEXT: 0610: 00F4BA00 F4BA9CFB E401B318 FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 0620: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 0630: FFFFFFFF 01B31800 FBDB00FB DB00FBDB |................|
|
|
|
|
|
CHECK-NEXT: 0640: 00FBDB00 FBDB00FB DB01B318 FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 0650: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 0660: FFFFFFFF 9FE2A801 B31801B3 1801B318 |................|
|
|
|
|
|
CHECK-NEXT: 0670: 01B31801 B31801B3 1861D06F FFFFFFFF |.........a.o....|
|
|
|
|
|
CHECK-NEXT: 0680: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 0690: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 06A0: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 06B0: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 06C0: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 06D0: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 06E0: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 06F0: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 0700: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 0710: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 0720: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 0730: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
|
|
|
|
|
CHECK-NEXT: 0740: FFFFFFFF FFFFFFFF 00000000 00006400 |..............d.|
|
|
|
|
|
CHECK-NEXT: 0750: 79007500 00000000 65007300 68006100 |y.u.....e.s.h.a.|
|
|
|
|
|
CHECK-NEXT: 0760: 6C006100 00008000 66006B00 61006F00 |l.a.....f.k.a.o.|
|
|
|
|
|
CHECK-NEXT: 0770: 79006100 00000000 0000C080 00000000 |y.a.............|
|
|
|
|
|
CHECK-NEXT: 0780: 02000A00 0A00C800 2C010000 00005400 |........,.....T.|
|
|
|
|
|
CHECK-NEXT: 0790: 65007300 74000000 01000250 00000000 |e.s.t......P....|
|
|
|
|
|
CHECK-NEXT: 07A0: 0A000A00 E6000E00 0100FFFF 82004300 |..............C.|
|
|
|
|
|
CHECK-NEXT: 07B0: 6F006E00 74006900 6E007500 65003A00 |o.n.t.i.n.u.e.:.|
|
|
|
|
|
CHECK-NEXT: 07C0: 00000000 00000150 00000000 42008600 |.......P....B...|
|
|
|
|
|
CHECK-NEXT: 07D0: A1000D00 0200FFFF 80002600 4F004B00 |..........&.O.K.|
|
|
|
|
|
CHECK-NEXT: 07E0: 00000000 00000000 11005800 A4000000 |..........X.....|
|
|
|
|
|
CHECK-NEXT: 07F0: 0D004800 2E160000 82001200 BC010000 |..H.............|
|
|
|
|
|
CHECK-NEXT: 0800: 00000000 00006400 66006900 73006800 |......d.f.i.s.h.|
|
|
|
|
|
CHECK-NEXT: 0810: 00000000 65007300 61006C00 61006400 |....e.s.a.l.a.d.|
|
|
|
|
|
CHECK-NEXT: 0820: 00008000 66006400 75006300 6B000000 |....f.d.u.c.k...|
|
|
|
|
|
CHECK-NEXT: 0830: 74686973 20697320 61207573 65722064 |this is a user d|
|
|
|
|
|
CHECK-NEXT: 0840: 6566696E 65642072 65736F75 72636500 |efined resource.|
|
|
|
|
|
CHECK-NEXT: 0850: 69742063 6F6E7461 696E7320 6D616E79 |it contains many|
|
|
|
|
|
CHECK-NEXT: 0860: 20737472 696E6773 00000000 00000000 | strings........|
|
|
|
|
|
CHECK-NEXT: )
|
