[ Follow up to discussion at https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01542.html ]
Pre-9 gcc generates this tls sequence for fPIC on x86_64:
0x00 .byte 0x66
0x01 leaq x@tlsgd(%rip),%rdi
0x08 .word 0x6666
0x0b call __tls_get_addr@plt
When compiling with -g, a .loc before the tls sequence is associated with the first insn in the tls sequence, which is the leaq, so it points inside the sequence rather than to the start of the sequence. Then, when ld relaxes the sequence, the .loc may end up pointing inside an insn (maybe we want at least a warning from ld there?). This will cause an executable containing such a misplaced .loc to crash when gdb continues from the associated breakpoint.
This problem has been fixed in gcc 9 in an architecture-specific way: by using arch-specific prefix data16 instead of .byte 0x66.
It would be nice if we could somehow have a generic way in gas to indicate start (and maybe end) of insn when using .byte/.value/.long/.quad to construct insns.
Or this, which allows us to express that the .byte is a
prefix to an existing insn:
For mips, there's an architecture-specific .insn directive already: https://sourceware.org/binutils/docs/as/MIPS-insn.html#MIPS-insn .
For some other archs, f.i. arm there's a .inst directive ( https://sourceware.org/binutils/docs/as/ARM-Directives.html#ARM-Directives ) which allows operands to be specified, but I'm not sure how much that makes sense for a generic directive.