Hi Tom,
> On 06/24/2018 11:56 PM, Jan Hubicka wrote:
>>> Hi,
>>>
>>> [ The analysis of this PR was done at https://stackoverflow.com/a/33557963 ,
>>> November 2015. ]
>>>
>>> This tls sequence:
>>> ...
>>> 0x00 .byte 0x66
>>> 0x01 leaq x@tlsgd(%rip),%rdi
>>> 0x08 .word 0x6666
>>> 0x0a rex64
>>> 0x0b call __tls_get_addr@plt
>>> ...
>>> starts with an insn prefix, produced using a .byte.
>>>
>>> When using a .loc before the sequence, it's associated with the next
>>> assembly
>>> instruction, which is the leaq, so the .loc will end up pointing inside the
>>> sequence rather than to the start of the sequence. And when the linker
>>> relaxes the sequence, the .loc may end up pointing inside an insn. This
>>> will
>>> cause an executable containing such a misplaced .loc to crash when gdb
>>> continues from the associated breakpoint.
>>
>> Hmm, I am not sure why .byte should be non-instruction and .data should
>> be instruction,
>> but I assume gas simply behaves this way.
>>
>
> Well, I suppose when encountering .byte/.value/.long/.quad, gas has no
> way of knowing whether it's dealing with data or instructions, even in
> the text section. An even if it would know it's dealing with
> instructions, it wouldn't know where an instruction begins or ends. So
> to me the behaviour seems reasonable.
>
> If we'd implemented something like this in gas:
> ...
> .insn
> .byte 0x66
> .endinsn
> ...
> we could fix this more generically.
>
> Or maybe we'd want 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
> ...
>
>> Don't we have also other cases wehre .byte is used to output instructions?
>>
>> Patch is OK (and probably should be backported after some soaking in
>> mainline)
>>
>
> Committed (after moving the testcase to gcc.target/i386).
the new testcase FAILs on 32-bit Solaris/x86
FAIL: gcc.target/i386/pr86257.c scan-assembler data16[ \\t]*leaq
and, according to gcc-testresults, also on i586-unknown-freebsd10.4 and
x86_64-pc-linux-gnu.
It's by design 64-bit only and should document that. Done as follows,
tested on i386-pc-solaris2.11 (both multilibs), installed on mainline.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
2018-06-26 Rainer Orth <r...@cebitec.uni-bielefeld.de>
* gcc.target/i386/pr86257.c: Require 64-bit.
# HG changeset patch
# Parent 68b96f5f97c10194b0d75108f730254c229bbf33
Require 64-bit in gcc.target/i386/pr86257.c
gcc/testsuite:
* gcc.target/i386/pr86257.c: Require 64-bit.
diff --git a/gcc/testsuite/gcc.target/i386/pr86257.c b/gcc/testsuite/gcc.target/i386/pr86257.c
--- a/gcc/testsuite/gcc.target/i386/pr86257.c
+++ b/gcc/testsuite/gcc.target/i386/pr86257.c
@@ -1,3 +1,4 @@
+/* { dg-require-effective-target lp64 } */
/* { dg-require-effective-target fpic } */
/* { dg-require-effective-target tls } */
/* { dg-options "-g -fPIC" } */
