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.
