[PATCH] D21731: fix bug 15393: invalid dwarf info on Win64
Jameson Nash via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed Dec 7 21:47:00 PST 2016
vtjnash added a comment.
the warnings in that test are from a different, related bug. An approximate correction for that is:
diff --git a/lib/CodeGen/AsmPrinter/DIE.cpp b/lib/CodeGen/AsmPrinter/DIE.cpp
index a328851..73977f2 100644
--- a/lib/CodeGen/AsmPrinter/DIE.cpp
+++ b/lib/CodeGen/AsmPrinter/DIE.cpp
@@ -495,7 +495,8 @@ void DIELabel::EmitValue(const AsmPrinter *AP, dwarf::Form Form) const {
AP->EmitLabelReference(Label, SizeOf(AP, Form),
Form == dwarf::DW_FORM_strp ||
Form == dwarf::DW_FORM_sec_offset ||
- Form == dwarf::DW_FORM_ref_addr);
+ Form == dwarf::DW_FORM_ref_addr ||
+ Form == dwarf::DW_FORM_data4);
}
/// SizeOf - Determine size of label value in bytes.
which should make the Dwarf 2 info more valid (I was only focused on Dwarf 4 information in this PR, which doesn't have the bug in the spec which makes that above diff necessary):
> The data in DW_FORM_data1, DW_FORM_data2, DW_FORM_data4 and DW_FORM_data8 can be anything. Depending on context, it may be an offset to a debugging information entry, a signed integer, an unsigned integer, a floating-point constant, or anything else. A consumer must use context to know how to interpret the bits, which if they are target machine data (such as an integer or floating point constant) will be in target machine byte-order.
The test failure is because we missed a case when developing that relocation code:
diff --git a/lib/CodeGen/AsmPrinter/AsmPrinter.cpp b/lib/CodeGen/AsmPrinter/AsmPrinter.cpp
index 9eba56d..263c9d6 100644
--- a/lib/CodeGen/AsmPrinter/AsmPrinter.cpp
+++ b/lib/CodeGen/AsmPrinter/AsmPrinter.cpp
@@ -1689,6 +1689,8 @@ void AsmPrinter::EmitLabelPlusOffset(const MCSymbol *Label, uint64_t Offset,
bool IsSectionRelative) const {
if (MAI->needsDwarfSectionOffsetDirective() && IsSectionRelative) {
OutStreamer->EmitCOFFSecRel32(Label, Offset);
+ if (Size > 4)
+ OutStreamer->EmitZeros(Size - 4);
return;
}
I'm pretty sure this should have an assertion too (`Size < UINT32_MAX && MAI->isLittleEndian()`). What kind of assert should I use in this case?
We can make this test fail on all buildbots by fixing the triple. Is there any reason not to do that?
diff --git a/test/Linker/type-unique-type-array-a.ll b/test/Linker/type-unique-type-array-a.ll
index f6c70df..60817ca 100644
--- a/test/Linker/type-unique-type-array-a.ll
+++ b/test/Linker/type-unique-type-array-a.ll
@@ -1,6 +1,8 @@
-; REQUIRES: default_triple, object-emission
+; REQUIRES: object-emission
;
-; RUN: llvm-link %s %p/type-unique-type-array-b.ll -S -o - | %llc_dwarf -filetype=obj -O0 | llvm-dwarfdump -debug-dump=info - | FileCheck %s
+; RUN: llvm-link %s %p/type-unique-type-array-b.ll -S -o - | %llc_dwarf -mtriple=x86_64-linux-gnu -filetype=obj -O0 | llvm-dwarfdump -debug-dump=info - | FileCheck %s
+; RUN: llvm-link %s %p/type-unique-type-array-b.ll -S -o - | %llc_dwarf -mtriple=x86_64-apple-darwin10 -filetype=obj -O0 | llvm-dwarfdump -debug-dump=info - | FileCheck %s
+; RUN: llvm-link %s %p/type-unique-type-array-b.ll -S -o - | %llc_dwarf -mtriple=x86_64-pc-mingw32 -filetype=obj -O0 | llvm-dwarfdump -debug-dump=info - | FileCheck %s
;
; rdar://problem/17628609
;
Repository:
rL LLVM
https://reviews.llvm.org/D21731
More information about the llvm-commits
mailing list