[Bug gas/30206] New: Missing line numbers for instructions coded with .byte, .short, .long and .quad

[iii at linux dot ibm.com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30206

            Bug ID: 30206
           Summary: Missing line numbers for instructions coded with
                    .byte, .short, .long and .quad
           Product: binutils
           Version: 2.41 (HEAD)
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gas
          Assignee: unassigned at sourceware dot org
          Reporter: iii at linux dot ibm.com
  Target Milestone: ---

I'm observing the following behavior for multiple architectures:

$ cat 1.s
xor %rax,%rax
.byte 0x90
xor %rbx,%rbx

$ as -g 1.s

$ objdump -dl a.out 
...
/tmp/1.s:1
   0:   48 31 c0                xor    %rax,%rax
   3:   90                      nop
/tmp/1.s:3
   4:   48 31 db                xor    %rbx,%rbx

Note that nop does not get a line number.
Using .insn instead of .byte helps, but I would like to understand whether this
is intentional?

The following patch helps on s390x:

--- a/gas/config/tc-s390.c
+++ b/gas/config/tc-s390.c
@@ -1215,6 +1215,7 @@ s390_elf_cons (int nbytes /* 1=.byte, 2=.word, 4=.long
*/)
        }
       else
        emit_expr (&exp, (unsigned int) nbytes);
+      dwarf2_emit_insn (nbytes);
     }
   while (*input_line_pointer++ == ',');

I wonder if it would make sense to implement something like this for all the
architectures?

The danger here that I can see is bloating the line numbers table, but this
seems to be mitigated already:
- The gnu assembler already does not emit line numbers for non-executable
sections.
- Sometimes gcc can put literal pool into executable sections, but it will not
emit the respective .loc directives.
- The only problematic case left is hand-written assembly that puts data into
executable sections, but how important is this case?

-- 
You are receiving this mail because:
You are on the CC list for the bug.