Updating .debug_line section version information to match DWARF version.

[kromanova]

Summary

Hello,
The compiler always emits .debug_line version 2, though some opcodes from DWARF 3 (e.g. DW_LNS_set_prologue_end, DW_LNS_set_epilogue_begin or DW_LNS_set_isa) and from DWARF 4 could be emitted by the compiler. That's not exactly right.

This patch changes version information of .debug_line to exactly match the DWARF version (which is 4 by default).
For .debug_line version 4, a new field maximum_operations_per_instruction is emitted. I'm not exactly sure how to set this field correctly for VLIW architectures. Hopefully, there are some experts in the community that could help out (any Hexagon debuginfo developers out there?).

I’ve tried a few tools to check if they could handle .debug_line version 4.
On a simple testcase, I verified that GDB debugger 7.7 understands .debug_line version 4.
Sony’s proprietary debugger can understand it too.
I don't have LLDB built, so I haven’t tried it.
GCC (older version 4.8.2) still emits version 2 for the .debug_line section, even though the DWARF version is set to 4. I'm not sure about the latest GCC.
GNU's readelf (version 2.24) can handle .debug_line version 4.

I added 3 new tests debug-line-version2.ll, debug-line-version3.ll and debug-line-version4.ll. The IR is generated from one source using different options (-gdwarf-2, -gdwarf-3 and –gdwarf-4). Any idea how to merge these three tests into one?

Let me know what do you think about the patch.

[dblaikie]

+Adrian for Apple/LLDB perspective

One way to merge the tests would be to add another command line argument
into DwarfDebug (see the way the split-dwarf command line argument is
used), just for testing purposes. The command line argument can override
the value specified in the metadata - so you can have one input file for
the 3 different versions.

[probinson]

I added 3 new tests debug-line-version2.ll, debug-line-version3.ll and debug-line-version4.ll. The IR is generated from one source using different options (-gdwarf-2, -gdwarf-3 and –gdwarf-4). Any idea how to merge these three tests into one?

Don't start from a .ll file? Your code change is in MC, so it's fine to test this with llvm-mc starting from assembler source. llvm-mc has a -dwarf-version option so you can control the version and the associated checks from the RUN line.
I see that test/MC/ELF/gen-dwarf.s does this kind of thing, for example.
And test/MC/ARM/dwarf-asm-multiple-sections.s seems to have accumulated version tests of this nature.

lib/MC/MCDwarf.cpp

283

The other state-machine parameters are all pretty obvious, but a raw "1" is not, so it ought to have a comment.

[kromanova]

Here is the revised patch. I have addressed Paul Robinson's comments.
Sorry for the delay. Somehow this patch patch fell off my radar.

Question: If you grep LLVM sources for " DWARF2Line, you'll see that a lot of identifier names imply that line_table is DWARF2. e.g. "DWARF2LineOpcodeBase". I suspect this should be changed to avoid confusion. Do you agree? Separate NFC patch?

[kromanova]

Adding Krzysztof Parzyszek to answer a question on how current patch changing .debug_line match the emitted DWARF version (which is 4 by default) affects Hexagon and to note that additional work is needed to set up maximum_operations_per_instruction field correctly for VLIW platforms.

[probinson]

In D16697#566445, @kromanova wrote:

Question: If you grep LLVM sources for " DWARF2Line, you'll see that a lot of identifier names imply that line_table is DWARF2. e.g. "DWARF2LineOpcodeBase". I suspect this should be changed to avoid confusion. Do you agree? Separate NFC patch?

Seems reasonable to me but I would generally expect that kind of name-change patch to be done separately.

[kromanova]

Question: If you grep LLVM sources for " DWARF2Line, you'll see that a lot of identifier names imply that line_table is DWARF2. e.g. "DWARF2LineOpcodeBase". I suspect this should be changed to avoid confusion. Do you agree? Separate NFC patch?

Seems reasonable to me but I would generally expect that kind of name-change patch to be done separately.

That sounds good. I will do it after this patch is accepted. I would really like to get this patch reviewed (and tested) by someone who cares about VLIW.

[echristo]

Seems entirely reasonable. Not sure what to do about the hexagon port - also, what do you have in mind for them to fix this? Check the target?

test/DebugInfo/X86/debug-line-version.s

7

"generate"

[kromanova]

In D16697#569986, @echristo wrote:

Not sure what to do about the hexagon port - also, what do you have in mind for them to fix this? Check the target?

Hi Eric,
Thank you for the review!

For Hexagon (or any other VLIW architecture) it will be necessary to check the target and implement support for 'op_index' register. I don’t think I will be the right person to implement support for calculating operation pointer within the bundle for VLIW architectures. I won’t be able to check/test that it works correctly.

I’m also quite concerned that not everyone who cares will actually read this patch. It might break some consumer tools like debuggers and dwarf dumpers, because they are not aware of maximum_operations_per_instruction field. I checked that “main suspects” GDB (version 7.7), readelf (version 2.24), latest llvm-dwarfdump understand maximum_operations_per_instruction; however, obviously, that’s not a complete list of debug info consumers.

Taking all this information into consideration, should I go ahead and commit? I have fixed the typo that you noticed.

Katya

[echristo]

Let's go ahead and add Krzysztof to this thread so he's aware for the Hexagon port and whether or not his debugger understands op_index at all. This patch may need to be conditionalized on that to avoid something going haywire.

-eric

[kparzysz]

Thanks, this is actually important for us. I'll get someone more familiar with the subject to take a look.

[kromanova]

In D16697#573573, @kparzysz wrote:

Thanks, this is actually important for us. I'll get someone more familiar with the subject to take a look.

Thank you! Please let me know how this patch will affect your tools.

[kparzysz]

Based on the discussion on lldb-dev, this seems ok. LGTM.

[echristo]

OK, let's go ahead and commit and go from there.

Thanks for your patience here.

-eric

[kromanova]

Great! Thank you. I will rebase and commit.

[kromanova]

I have committed this patch today r285355 and have to revert it shortly in r285362 because of two reasons:

(1) Unfortunately, some of the sanitizer tests failed with the following error.

Command Output (stdout):
--
while processing /var/folders/09/r4vw4v8n5kb67jl66zvlbljw0000gn/T/lit_tmp_XSTjqx/closed-fds-412f78.o:
warning: line table paramters mismatch. Cannot emit.
Closing streams.

--
Command Output (stderr):
--
/Users/buildslave/jenkins/sharedspace/phase1@2/llvm/projects/compiler-rt/test/asan/TestCases/Posix/closed-fds.cc:31:17: error: expected string not found in input
// CHECK-FILE: {{ #0 0x.* in main .*closed-fds.cc:}}[[@LINE-4]]
                ^
<stdin>:25:2: note: scanning from here
#0 0x49b2d in main (/Users/buildslave/jenkins/sharedspace/phase1@2/clang-build/projects/compiler-rt/test/asan/I386DarwinConfig/TestCases/Posix/Output/closed-fds.cc.tmp+0x1b2d)
^

Here is the link with the failure that buildbot sent me:
http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA_check/22826/
I'm not sure why these tests are failing. I have re-run all the sanitizer tests on my machines (x86-64 linux) and I didn't see any failures. Any clues?

(2) Some tests failed because the generated length of the line table was different from the expected value of
// DWARF2-NEXT: total_length: 0x00000077
For some of the tested configurations the generated total_length was 0x0000008c, 0x00000091 or 0x00000089.

There are lot of tests in LLVM regression test suite that check against hardcoded value of line table length, so I used similar strategy. I wonder what's so special about this particular case and why is the length of line table is different.

I guess, in this particular test it's not necessary to check against a hardcoded value of the line table length. Instead, I could just make sure that for DWARF2 and DWARF3 we generate the length of the table 'X' and for DWARF4, we generate length 'X+1'. I'm not sure if it's easy to do with FileCheck. Can we use pattern matching in FileCheck to capture [[X]], when patterns are in different test configuration (i.e. being tested with different -check-prefix)? Can we use captured value in expressions to calculate [[X+1]] similar to how it's done with [[@LINE]]?

Script:
--
/home/buildbots/ppc64le-clang-lnt-test/clang-ppc64le-lnt/stage1/./bin/llvm-mc -g -dwarf-version 2 -triple  i686-pc-linux-gnu /home/buildbots/ppc64le-clang-lnt-test/clang-ppc64le-lnt/llvm/test/DebugInfo/X86/debug-line-version.s -filetype=obj -o - | /home/buildbots/ppc64le-clang-lnt-test/clang-ppc64le-lnt/stage1/./bin/llvm-dwarfdump - | /home/buildbots/ppc64le-clang-lnt-test/clang-ppc64le-lnt/stage1/./bin/FileCheck --check-prefix=DWARF2 /home/buildbots/ppc64le-clang-lnt-test/clang-ppc64le-lnt/llvm/test/DebugInfo/X86/debug-line-version.s
/home/buildbots/ppc64le-clang-lnt-test/clang-ppc64le-lnt/stage1/./bin/llvm-mc -g -dwarf-version 3 -triple  i686-pc-linux-gnu /home/buildbots/ppc64le-clang-lnt-test/clang-ppc64le-lnt/llvm/test/DebugInfo/X86/debug-line-version.s -filetype=obj -o -  |/home/buildbots/ppc64le-clang-lnt-test/clang-ppc64le-lnt/stage1/./bin/llvm-dwarfdump - | /home/buildbots/ppc64le-clang-lnt-test/clang-ppc64le-lnt/stage1/./bin/FileCheck --check-prefix=DWARF3 /home/buildbots/ppc64le-clang-lnt-test/clang-ppc64le-lnt/llvm/test/DebugInfo/X86/debug-line-version.s
/home/buildbots/ppc64le-clang-lnt-test/clang-ppc64le-lnt/stage1/./bin/llvm-mc -g -dwarf-version 4 -triple  i686-pc-linux-gnu /home/buildbots/ppc64le-clang-lnt-test/clang-ppc64le-lnt/llvm/test/DebugInfo/X86/debug-line-version.s -filetype=obj -o - | /home/buildbots/ppc64le-clang-lnt-test/clang-ppc64le-lnt/stage1/./bin/llvm-dwarfdump - | /home/buildbots/ppc64le-clang-lnt-test/clang-ppc64le-lnt/stage1/./bin/FileCheck  --check-prefix=DWARF4 /home/buildbots/ppc64le-clang-lnt-test/clang-ppc64le-lnt/llvm/test/DebugInfo/X86/debug-line-version.s
--
Exit Code: 1

Command Output (stderr):
--
/home/buildbots/ppc64le-clang-lnt-test/clang-ppc64le-lnt/llvm/test/DebugInfo/X86/debug-line-version.s:20:17: error: expected string not found in input
// DWARF2-NEXT: total_length: 0x00000077
                ^
<stdin>:67:2: note: scanning from here
 total_length: 0x00000091
 ^

[kromanova]

I have committed this patch today r285355 and have to revert it shortly in r285362, because some tests were failing.

Sorry, this patch fell out of my radar for a while. Yesterday I investigated why the tests failed sometimes ( (the size of the line_table varied depending on the full file name and we check the size of line_table). I have updated the test not to depend on the full file name. When this patch gets approved, I will re-commit it.

[probinson]

Test update LGTM.

lib/MC/MCDwarf.cpp

MCDwarfLineTableHeader::Emit(MCStreamer *MCOS, MCDwarfLineTableParams Params,
   // Create a symbol for the end of the section (to be set when we get there).
   MCSymbol *LineEndSym = context.createTempSymbol();
 
   // The first 4 bytes is the total length of the information for this
   // compilation unit (not including these 4 bytes for the length).
   emitAbsValue(*MCOS,
                MakeStartMinusEndExpr(*MCOS, *LineStartSym, *LineEndSym, 4), 4);
 
-  // Next 2 bytes is the Version, which is Dwarf 2.
-  MCOS->EmitIntValue(2, 2);
+  // Next 2 bytes is the Version.
+  MCOS->EmitIntValue(context.getDwarfVersion(), 2);
 
   // Create a symbol for the end of the prologue (to be set when we get there).
   MCSymbol *ProEndSym = context.createTempSymbol(); // Lprologue_end
 
   // Length of the prologue, is the next 4 bytes.  Which is the start of the
   // section to the end of the prologue.  Not including the 4 bytes for the
   // total length, the 2 bytes for the version, and these 4 bytes for the
   // length of the prologue.
   emitAbsValue(
       *MCOS,
       MakeStartMinusEndExpr(*MCOS, *LineStartSym, *ProEndSym, (4 + 2 + 4)), 4);
 
   // Parameters of the state machine, are next.
   MCOS->EmitIntValue(context.getAsmInfo()->getMinInstAlignment(), 1);
+  // maximum_operations_per_instruction 
+  // For non-VLIW architectures this field is always 1.
+  // FIXME: VLIW architectures need to update this field accordingly.
+  if (context.getDwarfVersion() >= 4)
+    MCOS->EmitIntValue(1, 1);
   MCOS->EmitIntValue(DWARF2_LINE_DEFAULT_IS_STMT, 1);
   MCOS->EmitIntValue(Params.DWARF2LineBase, 1);
   MCOS->EmitIntValue(Params.DWARF2LineRange, 1);
   MCOS->EmitIntValue(StandardOpcodeLengths.size() + 1, 1);
 
   // Standard opcode lengths
   for (char Length : StandardOpcodeLengths)
     MCOS->EmitIntValue(Length, 1);

test/DebugInfo/AArch64/line-header.ll

 ; RUN: llc -mtriple=aarch64-none-linux -O0 -filetype=obj - < %S/../Inputs/line.ll | llvm-dwarfdump - | FileCheck %s
 ; RUN: llc -mtriple=aarch64_be-none-linux -O0 -filetype=obj - < %S/../Inputs/line.ll | llvm-dwarfdump - | FileCheck %s
 
 ; check line table length is correctly calculated for both big and little endian
 CHECK-LABEL: .debug_line contents:
-CHECK: total_length: 0x0000003e
+CHECK: total_length: 0x0000003f

test/DebugInfo/Generic/empty.ll

 ; REQUIRES: object-emission
 
 ; RUN: %llc_dwarf < %s -filetype=obj | llvm-dwarfdump - | FileCheck %s
 ; RUN: %llc_dwarf -split-dwarf=Enable < %s -filetype=obj | llvm-dwarfdump - | FileCheck --check-prefix=FISSION %s
 
 ; darwin has a workaround for a linker bug so it always emits one line table entry
 ; XFAIL: darwin
 
 ; Expect no line table entry since there are no functions and file references in this compile unit
 ; CHECK: .debug_line contents:
 ; CHECK: Line table prologue:
-; CHECK: total_length: 0x00000019
+; CHECK: total_length: 0x0000001a
 ; CHECK-NOT: file_names[
 
 ; CHECK: .debug_pubnames contents:
 ; CHECK-NOT: Offset
 
 ; CHECK: .debug_pubtypes contents:
 ; CHECK-NOT: Offset
 

test/DebugInfo/X86/debug-line-version.s

+// RUN: llvm-mc -dwarf-version 2 -triple  i686-pc-linux-gnu %s -filetype=obj -o - | llvm-readobj -r -s -sd | FileCheck --check-prefixes=DWARF,DWARF2 %s
+// RUN: llvm-mc -dwarf-version 3 -triple  i686-pc-linux-gnu %s -filetype=obj -o - | llvm-readobj -r -s -sd | FileCheck --check-prefixes=DWARF,DWARF3 %s
+// RUN: llvm-mc -dwarf-version 4 -triple  i686-pc-linux-gnu %s -filetype=obj -o - | llvm-readobj -r -s -sd | FileCheck --check-prefixes=DWARF,DWARF4 %s
+
+// DWARF:    Name: .debug_line (11)
+// DWARF-NEXT:    Type: SHT_PROGBITS (0x1)
+// DWARF-NEXT:    Flags [ (0x0)
+// DWARF-NEXT:    ]
+// DWARF-NEXT:    Address: 0x0
+// DWARF-NEXT:    Offset: 0x35
+// DWARF2-NEXT:    Size: 51
+// DWARF3-NEXT:    Size: 51
+// DWARF4-NEXT:    Size: 52
+// DWARF-NEXT:    Link: 0
+// DWARF-NEXT:    Info: 0
+// DWARF-NEXT:    AddressAlignment: 1
+// DWARF-NEXT:    EntrySize: 0
+// DWARF2-NEXT:    SectionData (
+// DWARF2-NEXT:      0000: 2F000000 02001A00 00000101 FB0E0D00  |/...............|
+// DWARF2-NEXT:      0010: 01010101 00000001 00000100 666F6F00  |............foo.|
+// DWARF2-NEXT:      0020: 00000000 00050200 00000003 3F010201  |............?...|
+// DWARF2-NEXT:      0030: 000101                               |...|
+// DWARF2-NEXT:    )
+// DWARF3-NEXT:    SectionData (
+// DWARF3-NEXT:      0000: 2F000000 03001A00 00000101 FB0E0D00  |/...............|
+// DWARF3-NEXT:      0010: 01010101 00000001 00000100 666F6F00  |............foo.|
+// DWARF3-NEXT:      0020: 00000000 00050200 00000003 3F010201  |............?...|
+// DWARF3-NEXT:      0030: 000101                               |...|
+// DWARF3-NEXT:    )
+// DWARF4-NEXT:    SectionData (
+// DWARF4-NEXT:      0000: 30000000 04001B00 00000101 01FB0E0D  |0...............|
+// DWARF4-NEXT:      0010: 00010101 01000000 01000001 00666F6F  |.............foo|
+// DWARF4-NEXT:      0020: 00000000 00000502 00000000 033F0102  |.............?..|
+// DWARF4-NEXT:      0030: 01000101                             |....|
+// DWARF4-NEXT:    )
+
+        .file   1 "foo"
+        .loc    1 64 0
+        nop

test/DebugInfo/X86/empty.ll

 ; RUN: llc -mtriple i686-pc-cygwin < %s -filetype=obj | llvm-dwarfdump - | FileCheck %s
 ; RUN: llc -mtriple i686-pc-cygwin -split-dwarf=Enable < %s -filetype=obj | llvm-dwarfdump - | FileCheck --check-prefix=FISSION %s
 
 ; Expect no line table entry since there are no functions and file references in this compile unit
 ; CHECK: .debug_line contents:
 ; CHECK: Line table prologue:
-; CHECK: total_length: 0x00000019
+; CHECK: total_length: 0x0000001a
 ; CHECK-NOT: file_names[
 
 ; CHECK: .debug_pubnames contents:
 ; CHECK-NOT: Offset
 
 ; CHECK: .debug_pubtypes contents:
 ; CHECK-NOT: Offset
 

test/DebugInfo/X86/stmt-list-multiple-compile-units.ll

 ; CHECK: DW_AT_stmt_list [DW_FORM_sec_offset]   (0x00000000)
 ; CHECK: DW_AT_low_pc [DW_FORM_addr]            (0x0000000000000000)
 ; CHECK: DW_AT_high_pc [DW_FORM_data4]          (0x00000010)
 ; CHECK: DW_TAG_subprogram
 ; CHECK: DW_AT_low_pc [DW_FORM_addr]            (0x0000000000000000)
 ; CHECK: DW_AT_high_pc [DW_FORM_data4]          (0x00000010)
 
 ; CHECK: DW_TAG_compile_unit
-; CHECK: DW_AT_stmt_list [DW_FORM_sec_offset]   (0x0000003c)
+; CHECK: DW_AT_stmt_list [DW_FORM_sec_offset]   (0x0000003d)
 ; CHECK: DW_AT_low_pc [DW_FORM_addr]            (0x0000000000000010)
 ; CHECK: DW_AT_high_pc [DW_FORM_data4]          (0x00000009)
 ; CHECK: DW_TAG_subprogram
 ; CHECK: DW_AT_low_pc [DW_FORM_addr]            (0x0000000000000010)
 ; CHECK: DW_AT_high_pc [DW_FORM_data4]          (0x00000009)
 
 
 ; CHECK: .debug_line contents:
 ; CHECK-NEXT: Line table prologue:
-; CHECK-NEXT: total_length: 0x00000038
+; CHECK-NEXT: total_length: 0x00000039
 ; CHECK: file_names[  1]    0 0x00000000 0x00000000 simple.c
 ; CHECK: Line table prologue:
-; CHECK-NEXT: total_length: 0x00000039
+; CHECK-NEXT: total_length: 0x0000003a
 ; CHECK: file_names[  1]    0 0x00000000 0x00000000 simple2.c
 ; CHECK-NOT: file_names
 
 ; DWARF3: .debug_info contents:
 ; DWARF3: DW_TAG_compile_unit
 ; DWARF3: DW_AT_stmt_list [DW_FORM_data4]    (0x00000000)
 
 ; DWARF3: DW_TAG_compile_unit

test/MC/ELF/debug-line.s

 
 // CHECK:        Section {
 // CHECK:          Name: .debug_line
 // CHECK-NEXT:     Type: SHT_PROGBITS
 // CHECK-NEXT:     Flags [
 // CHECK-NEXT:     ]
 // CHECK-NEXT:     Address: 0x0
 // CHECK-NEXT:     Offset:
-// CHECK-NEXT:     Size: 57
+// CHECK-NEXT:     Size: 58
 // CHECK-NEXT:     Link: 0
 // CHECK-NEXT:     Info: 0
 // CHECK-NEXT:     AddressAlignment: 1
 // CHECK-NEXT:     EntrySize: 0
 // CHECK-NEXT:     SectionData (
 
-// CHECK-NEXT:       0000: 35000000 02001C00 00000101 FB0E0D00
-// CHECK-NEXT:       0010: 01010101 00000001 00000100 666F6F2E
-// CHECK-NEXT:       0020: 63000000 00000009 02000000 00000000
-// CHECK-NEXT:       0030: 00154B21 02080001 01
+// CHECK-NEXT:       0000: 36000000 04001D00 00000101 01FB0E0D
+// CHECK-NEXT:       0010: 00010101 01000000 01000001 00666F6F  
+// CHECK-NEXT:       0020: 2E630000 00000000 09020000 00000000  
+// CHECK-NEXT:       0030: 0000154B 21020800 0101              
 // CHECK-NEXT:     )
 // CHECK-NEXT:   }
 
   .section  .debug_line,"",@progbits
   .text
 
   .file 1 "foo.c"
   .loc 1 4 0

test/MC/ELF/debug-line2.s

 // RUN: llvm-mc -filetype=obj -triple x86_64-pc-linux-gnu %s -o - | llvm-readobj -s -sd | FileCheck %s
 
 // Test that two subsequent .loc directives generate two
 // distinct line table entries.
 
 // CHECK:        Section {
 // CHECK:          Name: .debug_line
 // CHECK-NEXT:     Type: SHT_PROGBITS
 // CHECK-NEXT:     Flags [
 // CHECK-NEXT:     ]
 // CHECK-NEXT:     Address: 0x0
 // CHECK-NEXT:     Offset:
-// CHECK-NEXT:     Size: 56
+// CHECK-NEXT:     Size: 57
 // CHECK-NEXT:     Link: 0
 // CHECK-NEXT:     Info: 0
 // CHECK-NEXT:     AddressAlignment: 1
 // CHECK-NEXT:     EntrySize: 0
 // CHECK-NEXT:     SectionData (
-// CHECK-NEXT:       0000: 34000000 02001C00 00000101 FB0E0D00
-// CHECK-NEXT:       0010: 01010101 00000001 00000100 666F6F2E
-// CHECK-NEXT:       0020: 63000000 00000009 02000000 00000000
-// CHECK-NEXT:       0030: 00011302 01000101
+// CHECK-NEXT:       0000: 35000000 04001D00 00000101 01FB0E0D  |5...............|
+// CHECK-NEXT:       0010: 00010101 01000000 01000001 00666F6F  |.............foo|
+// CHECK-NEXT:       0020: 2E630000 00000000 09020000 00000000  |.c..............|
+// CHECK-NEXT:       0030: 00000113 02010001 01                 |.........|
 // CHECK-NEXT:     )
 // CHECK-NEXT:   }
 
   .section  .debug_line,"",@progbits
   .text
 
   .file 1 "foo.c"
   .loc 1 1 0
   .loc 1 2 0
   nop

test/MC/ELF/debug-loc.s

 // CHECK:        Section {
 // CHECK:          Index:
 // CHECK:          Name: .debug_line
 // CHECK-NEXT:     Type: SHT_PROGBITS
 // CHECK-NEXT:     Flags [
 // CHECK-NEXT:     ]
 // CHECK-NEXT:     Address: 0x0
 // CHECK-NEXT:     Offset:
-// CHECK-NEXT:     Size: 61
+// CHECK-NEXT:     Size: 62
 // CHECK-NEXT:     Link: 0
 // CHECK-NEXT:     Info: 0
 // CHECK-NEXT:     AddressAlignment: 1
 // CHECK-NEXT:     EntrySize: 0
 // CHECK-NEXT:   }
 
   .section  .debug_line,"",@progbits
   .text
 foo:
   .file 1 "Driver.ii"
   .loc 1 2 0
         nop
   .loc 1 4 0
         nop
   .loc 1 3 0
         nop

test/MC/ELF/discriminator.s

.L.debug_abbrev_begin:
         .byte   0                       # EOM(1)
         .byte   0                       # EOM(2)
         .byte   0                       # EOM(3)
 .L.debug_abbrev_end:
 
 
 # CHECK:      Relocations [
 # CHECK:        Section ({{[^ ]+}}) .rel.debug_line {
-# CHECK-NEXT:     0x2D R_386_32 .text 0x0
+# CHECK-NEXT:     0x2E R_386_32 .text 0x0
 # CHECK-NEXT:   }
 
 # DWARF-DUMP: Address            Line   Column File   ISA Discriminator Flags
 # DWARF-DUMP: ------------------ ------ ------ ------ --- ------------- -------------
 # DWARF-DUMP: 0x0001021300000000     1      0      1   0             1  is_stmt

test/MC/ELF/empty-dwarf-lines.s

 // CHECK:        Section {
 // CHECK:          Index:
 // CHECK:          Name: .debug_line
 // CHECK-NEXT:     Type: SHT_PROGBITS
 // CHECK-NEXT:     Flags [
 // CHECK-NEXT:     ]
 // CHECK-NEXT:     Address: 0x0
 // CHECK-NEXT:     Offset: 0x44
-// CHECK-NEXT:     Size: 39
+// CHECK-NEXT:     Size: 40
 // CHECK-NEXT:     Link: 0
 // CHECK-NEXT:     Info: 0
 // CHECK-NEXT:     AddressAlignment: 1
 // CHECK-NEXT:     EntrySize: 0
 // CHECK-NEXT:   }

test/MC/MachO/file.s

 // RUN: llvm-mc -triple i386-apple-darwin9 %s -filetype=obj -o - | llvm-readobj -s -section-data | FileCheck %s
 
         .file 1 "dir/foo"
         nop
 
 // CHECK:       Section {
 // CHECK:         Index: 1
 // CHECK-NEXT:    Name: __debug_line
 // CHECK-NEXT:    Segment: __DWARF
 // CHECK-NEXT:    Address: 0x1
-// CHECK-NEXT:    Size: 0x28
+// CHECK-NEXT:    Size: 0x29
 // CHECK-NEXT:    Offset: 237
 // CHECK-NEXT:    Alignment: 0
 // CHECK-NEXT:    RelocationOffset: 0x0
 // CHECK-NEXT:    RelocationCount: 0
 // CHECK-NEXT:    Type: 0x0
 // CHECK-NEXT:    Attributes [ (0x20000)
 // CHECK-NEXT:      Debug (0x20000)
 // CHECK-NEXT:    ]
 // CHECK-NEXT:    Reserved1: 0x0
 // CHECK-NEXT:    Reserved2: 0x0
 // CHECK-NEXT:    SectionData (
-// CHECK-NEXT:      0000: 24000000 02001E00 00000101 FB0E0D00
-// CHECK-NEXT:      0010: 01010101 00000001 00000164 69720000
-// CHECK-NEXT:      0020: 666F6F00 01000000
+// CHECK-NEXT:      0000: 25000000 04001F00 00000101 01FB0E0D  |%...............|
+// CHECK-NEXT:      0010: 00010101 01000000 01000001 64697200  |............dir.|
+// CHECK-NEXT:      0020: 00666F6F 00010000 00                 |.foo.....|
 // CHECK-NEXT:    )
 // CHECK-NEXT:  }

test/MC/MachO/gen-dwarf.s

 // CHECK:    NULL
 
 // CHECK: .debug_aranges contents:
 // CHECK: Address Range Header: length = 0x0000001c, version = 0x0002, cu_offset = 0x00000000, addr_size = 0x04, seg_size = 0x00
 
 // CHECK: .debug_line contents:
 // CHECK: Line table prologue:
 // We don't check the total_length as it includes lengths of temp paths
-// CHECK:         version: 2
+// CHECK:         version: 4
 // We don't check the prologue_length as it too includes lengths of temp paths
 // CHECK: min_inst_length: 1
 // CHECK: default_is_stmt: 1
 // CHECK:       line_base: -5
 // CHECK:      line_range: 14
 // CHECK:     opcode_base: 13
 // CHECK: standard_opcode_lengths[DW_LNS_copy] = 0
 // CHECK: standard_opcode_lengths[DW_LNS_advance_pc] = 1

test/MC/MachO/loc.s

 // RUN: llvm-mc -triple i386-apple-darwin9 %s -filetype=obj -o - | llvm-readobj -r -s -sd | FileCheck %s
 
         .file 1 "foo"
   .loc  1 64 0
         nop
 
 // CHECK: Section {
 // CHECK:     Index: 1
 // CHECK:     Name: __debug_line (5F 5F 64 65 62 75 67 5F 6C 69 6E 65 00 00 00 00)
 // CHECK:     Segment: __DWARF (5F 5F 44 57 41 52 46 00 00 00 00 00 00 00 00 00)
 // CHECK:     Address: 0x1
-// CHECK:     Size: 0x33
+// CHECK:     Size: 0x34
 // CHECK:     Offset: 237
 // CHECK:     Alignment: 0
-// CHECK:     RelocationOffset: 0x120
+// CHECK:     RelocationOffset: 0x124
 // CHECK:     RelocationCount: 1
 // CHECK:     Type: 0x0
 // CHECK:     Attributes [ (0x20000)
 // CHECK:       Debug (0x20000)
 // CHECK:     ]
 // CHECK:     Reserved1: 0x0
 // CHECK:     Reserved2: 0x0
 // CHECK:     SectionData (
-// CHECK:       0000: 2F000000 02001A00 00000101 FB0E0D00  |/...............|
-// CHECK:       0010: 01010101 00000001 00000100 666F6F00  |............foo.|
-// CHECK:       0020: 00000000 00050200 00000003 3F010201  |............?...|
-// CHECK:       0030: 000101                               |...|
+// CHECK:       0000: 30000000 04001B00 00000101 01FB0E0D  |0...............|
+// CHECK:       0010: 00010101 01000000 01000001 00666F6F  |.............foo|
+// CHECK:       0020: 00000000 00000502 00000000 033F0102  |.............?..|
+// CHECK:       0030: 01000101   
 // CHECK:     )
 // CHECK:   }
 // CHECK: ]
 // CHECK: Relocations [
 // CHECK:   Section __debug_line {
-// CHECK:     0x27 0 2 0 GENERIC_RELOC_VANILLA 0 __text
+// CHECK:     0x28 0 2 0 GENERIC_RELOC_VANILLA 0 __text
 // CHECK:   }
 // CHECK: ]