-
Notifications
You must be signed in to change notification settings - Fork 13.6k
[llvm-readobj] Support --string-table for COFF #141552
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,37 @@ | ||
# RUN: yaml2obj %s -o %t.obj | ||
# RUN: llvm-readobj --string-table %t.obj \ | ||
# RUN: %p/Inputs/coff-load-config-x64.dll \ | ||
# RUN: %p/Inputs/zero-string-table.obj.coff-i386 | FileCheck %s | ||
|
||
# CHECK-LABEL: File: {{.*}}string-table.test.tmp.obj | ||
# CHECK: StringTable { | ||
# CHECK-NEXT: Length: 31 | ||
# CHECK-NEXT: [ 4] .debug_str | ||
# CHECK-NEXT: [ f] _main_test_test | ||
# CHECK-NEXT: } | ||
|
||
# CHECK-LABEL: File: {{.*}}coff-load-config-x64.dll | ||
# CHECK: StringTable { | ||
# CHECK-NEXT: Length: 0 | ||
# CHECK-NEXT: } | ||
|
||
# CHECK-LABEL: File: {{.*}}zero-string-table.obj.coff-i386 | ||
# CHECK: StringTable { | ||
# CHECK-NEXT: Length: 4 | ||
# CHECK-NEXT: } | ||
|
||
--- !COFF | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Could you try simplifying this YAML a bit, by removing unnecessary fields/sections/symbols, please? In particular, you only need a couple of sections, just to populate the string table. |
||
header: | ||
Machine: IMAGE_FILE_MACHINE_AMD64 | ||
sections: | ||
- Name: .text | ||
Characteristics: [ IMAGE_SCN_CNT_CODE, IMAGE_SCN_MEM_EXECUTE, IMAGE_SCN_MEM_READ ] | ||
- Name: .debug_str | ||
Characteristics: [ IMAGE_SCN_CNT_INITIALIZED_DATA, IMAGE_SCN_MEM_DISCARDABLE, IMAGE_SCN_MEM_READ ] | ||
symbols: | ||
- Name: _main_test_test | ||
Value: 0 | ||
SectionNumber: 1 | ||
SimpleType: IMAGE_SYM_TYPE_NULL | ||
ComplexType: IMAGE_SYM_DTYPE_FUNCTION | ||
StorageClass: IMAGE_SYM_CLASS_EXTERNAL |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -157,8 +157,10 @@ class ObjDumper { | |
llvm::codeview::GlobalTypeTableBuilder &GlobalCVTypes, | ||
bool GHash) {} | ||
|
||
// Only implemented for XCOFF. | ||
// Only implemented for XCOFF/COFF. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This comment was previously intended to refer to all the following functions, since e.g. |
||
virtual void printStringTable() {} | ||
|
||
// Only implemented for XCOFF. | ||
virtual void printAuxiliaryHeader() {} | ||
virtual void printExceptionSection() {} | ||
virtual void printLoaderSection(bool PrintHeader, bool PrintSymbols, | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test doesn't cover the following significant cases:
Please add these, as they help ensure a robust llvm-readobj that doesn't crash when it gets something unexpected (or worse, start reading memory outside what it should). The malformed cases might require improvements to yaml2obj to allow you to create a string table with arbitrary values in the length field. This should be a separate PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that making
yaml2obj
produce malformed string tables is out of scope here; as the yaml representation doesn't contain the string table explicitly at all, but it is created implicitly from strings needed for symbols and sections, it would be a significant change/extension to the yaml format just for testing those invalid cases.So for testing those cases, practically, I think bundling a small binary file is the most pragmatic solution.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll leave you to judge that for the COFF side (although I think the general consensus is that prebuilt binaries should be avoided), but in general, it's precisely these sorts of cases that have led to incremental improvements on the ELF side of yaml2obj. In this particular situation, I'd add a new top-level YAML entry for the string table, which, if implemented, would override the default-generated one.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated test for empty stringtab.
StringTableSize has been set to at least 4 and there's assertion to make sure stringtable end must be '\0'.
llvm-project/llvm/lib/Object/COFFObjectFile.cpp
Lines 442 to 450 in 6da8f3b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That might well be what the code currently does, but the test needs to show that it does this. Otherwise, somebody might change how the code works and accidentally break existing behaviour, because it is untested. For example, somebody might decide the printing function should read the data directly, rather than rely on the existing library methods, but then forget to add these sort of conditions.
Anyway, that code looks suspect: what happens if the file ends fewer than 4 bytes after the end of the string table?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The string table llvm-readobj get from COFFObjectFile is StringRef.
I think it's COFFObjectFile's responsibility to make sure this StringRef is readable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're missing my point completely. I'm asking you to verify that the outward behaviour of llvm-readobj is correct through tests, not just reading the code. Putting it another way, it would not be impossible for somebody to decide that the COFFObjectFile interface is no longer the appropriate way to implement llvm-readobj for COFF and to implement something themselves that reads and prints COFF object information. In such a case, the tests should work for both the old and new implementation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As you mentioned this should be a new feature for yaml2obj in separate PR and that would benefit COFF as well as XCOFF.