[Bug breakpoints/22921] breakpoint in PLT corrupts function argument in $rcx

["aburgess at redhat dot com" <sourceware-bugzilla@sourceware.org>]

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

--- Comment #9 from Andrew Burgess <aburgess at redhat dot com> ---
Created attachment 14679
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14679&action=edit
Updated minimal reproducer

I understand the problem better now.  The issue as originally reported, and as
I had it in the first reproducer was very timing dependent.  The bug is for a
signal arriving during a displaced step.  As such it's not surprising that Stas
was unable to reproduce the issue with my first example.

However, now I know what the issue is, I've updated the reproducer.  Instead of
using a timer to deliver the signal I wait until I'm in the PLT, then send a
signal to the inferior using the shell.  After that I continue, GDB sets up the
displaced step, resumes the inferior, and immediately takes the signal.

Some consequence of the displaced step means that the inferior's $rcx value
becomes corrupted.

We might be tempted to try using 'queue-signal' from the GDB prompt, rather
than sending the signal via the shell, however, this will not work.  The signal
_HAS_ to arrive during the displaced step.  Using queue-signal means that GDB
doesn't perform the displaced step, and instead immediately sends the inferior
the signal.  To reproduce this bug the signal _must_ arrive during the
displaced step.

Finally, here's my GDB session showing the bug.  I've got some debug turned on,
and we can see where the corruption is coming from thanks to my annotated lines
(look for "<======="):

Breakpoint 2, 0x00007ffff7fc5070 in apb_magic_func(void*, char const*, int,
unsigned int)@plt () from ./libapb.so
1: x/i $pc
=> 0x7ffff7fc5070 <_Z14apb_magic_funcPvPKcij@plt>:      
    jmp    *0x2fc2(%rip)        # 0x7ffff7fc8038
<_Z14apb_magic_funcPvPKcij@got.plt>
2: /x $rcx = 0x200
+python cmd = "shell kill -s SIGALRM %d" % gdb.selected_inferior().pid
+python gdb.execute(cmd)
++shell kill -s SIGALRM 2799375
+continue
[displaced] displaced_step_prepare_throw: displaced-stepping 2799375.2799375.0
now
[displaced] prepare: selected buffer at 0x401072
[displaced] prepare: saved 0x401072: 1e fa 31 ed 49 89 d1 5e 48 89 e2 48 83 e4
f0 50
[displaced] fixup_riprel: %rip-relative addressing used.
[displaced] fixup_riprel: using temp reg 2, old value 0x200, new value
0x7ffff7fc5076   <============================== Note the "new" value here.
[displaced] amd64_displaced_step_copy_insn: copy 0x7ffff7fc5070->0x401072: ff
a1 c2 2f 00 00 68 04 00 00 00 e9 a0 ff ff ff
[displaced] displaced_step_prepare_throw: prepared successfully
thread=2799375.2799375.0, original_pc=0x7ffff7fc5070, displaced_pc=0x401072
[displaced] resume_1: run 0x401072: ff a1 c2 2f
[displaced] finish: restored 2799375.2799375.0 0x401072

Program received signal SIGALRM, Alarm clock.
[displaced] displaced_step_prepare_throw: displaced-stepping 2799375.2799375.0
now
[displaced] prepare: selected buffer at 0x401072
[displaced] prepare: saved 0x401072: 1e fa 31 ed 49 89 d1 5e 48 89 e2 48 83 e4
f0 50
[displaced] fixup_riprel: %rip-relative addressing used.
[displaced] fixup_riprel: using temp reg 2, old value 0x7ffff7fc5076, new value
0x7ffff7fc5076
[displaced] amd64_displaced_step_copy_insn: copy 0x7ffff7fc5070->0x401072: ff
a1 c2 2f 00 00 68 04 00 00 00 e9 a0 ff ff ff
[displaced] displaced_step_prepare_throw: prepared successfully
thread=2799375.2799375.0, original_pc=0x7ffff7fc5070, displaced_pc=0x401072
[displaced] resume_1: run 0x401072: ff a1 c2 2f
[displaced] finish: restored 2799375.2799375.0 0x401072
[displaced] amd64_displaced_step_fixup: fixup (0x7ffff7fc5070, 0x401072), insn
= 0xff 0xa1 ...
[displaced] amd64_displaced_step_fixup: restoring reg 2 to 0x7ffff7fc5076
FAILED: 4160508022 (0xf7fc5076)  <============================== Look familiar?
 It's the lower 32-bits of the "new" value!

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