Bug 23423 - generic directive to mark data as insn
Summary: generic directive to mark data as insn
Status: NEW
Alias: None
Product: binutils
Classification: Unclassified
Component: gas (show other bugs)
Version: 2.32
: P2 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-07-17 16:16 UTC by Tom de Vries
Modified: 2018-07-17 16:16 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tom de Vries 2018-07-17 16:16:27 UTC
[ 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
0x0a rex64
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.

F.i.:
...
.insn
.byte 0x66
.endinsn
...

Or this, which allows us to express that the .byte is a
prefix to an existing insn:
...
.insn
.byte 0x66
leaq  x@tlsgd(%rip),%rdi
.endinsn
...

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.