[llvm-bugs] [Bug 45529] New: [MC][DWARF] Incorrect handling of is_stmt flag in .loc directives

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=45529

            Bug ID: 45529
           Summary: [MC][DWARF] Incorrect handling of is_stmt flag in .loc
                    directives
           Product: libraries
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: MC
          Assignee: unassignedbugs at nondot.org
          Reporter: dpreobrazhensky at luxoft.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 23353
  --> https://bugs.llvm.org/attachment.cgi?id=23353&action=edit
A simple test which demonstrates the issue

The .loc directive should mimic operations of .debug_line state machine.
For example, below is an excerpt from gcc asm manual: 

    .loc fileno lineno [column] [options]
        ...
        is_stmt value
            This option will set the is_stmt register in the .debug_line
            state machine to value, which must be either 0 or 1.

There is a subtlety regarding is_stmt: this flag should affect
all subsequent .loc directives. For example:

    .file 1 "test.c"
    .loc 1 2                # is_stmt=1 (initial value)
    nop
    .loc 1 4 is_stmt 0      # is_stmt=0
    nop
    .loc 1 6                # is_stmt=0 (affected by previous .loc)
    nop
    .loc 1 8 is_stmt 1      # is_stmt=1
    nop
    .loc 1 10               # is_stmt=1 (affected by previous .loc)
    nop

GCC assembler handles this code correctly and produces the following debug
info:

Address            Line   Column File   ISA Discriminator Flags
------------------ ------ ------ ------ --- ------------- -------------
0x0000000000000000      2      0      1   0             0  is_stmt
0x0000000000000001      4      0      1   0             0 
0x0000000000000002      6      0      1   0             0 
0x0000000000000003      8      0      1   0             0  is_stmt
0x0000000000000004     10      0      1   0             0  is_stmt
0x0000000000000005     10      0      1   0             0  is_stmt end_sequence

llvm assembler handles is_stmt differently. The value specified by is_stmt
does not affect subsequent .loc directives:

Address            Line   Column File   ISA Discriminator Flags
------------------ ------ ------ ------ --- ------------- -------------
0x0000000000000000      2      0      1   0             0  is_stmt
0x0000000000000001      4      0      1   0             0 
0x0000000000000002      6      0      1   0             0  is_stmt
0x0000000000000003      8      0      1   0             0  is_stmt
0x0000000000000004     10      0      1   0             0  is_stmt
0x0000000000000005     10      0      1   0             0  is_stmt end_sequence

This may look like a minor issue, however, it has negative consequences
for locations with line=0. The current llvm implementation forces these 
locations have is_stmt=1 unless is_stmt=0 is specified explicitly.
These cause the debugger to stop at unexpected code locations.

Also note that this is an llvm assembler specific issue.
if code-gen directly produces an object file, 
the generated debugging information is correct.

The issue may be reproduced using the enclosed test.s.
To assemble the test using GCC assembler, run the following commands:

    as -march=i386 -32 test.s -o test.o
    llvm-dwarfdump -debug-info -debug-line test.o

To assemble the test using llvm assembler, run the following commands:

    llvm-mc -triple i386-unknown-unknown -filetype=obj test.s -o test.o
    llvm-dwarfdump -debug-info -debug-line test.o

The following files may be helpful to compare direct object file
generation with 2-stage generation via MC. The resultant debugging
information differs in that MC assembler generates additional
is_stmt=1 flags where it should not.

    is_stmt_bug.linked.bc - code with some debugging information.
    is_stmt_bug.sh - a script which demonstrates the issue.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200414/9058b557/attachment.html>