Re: [PATCH] Guard against killing unrelated processes in amd64-disp-step.exp

[Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>]

Hi Pedro,

>> That's what I thought: if for whatever reason the pid turns
>> non-positive, hell breaks lose if that's passed to kill unchecked.
>> 
>>> this ends up as -1, and whether a fix belongs elsewhere.
>> 
>> gdb.log shows
>> 
>> (gdb) PASS: gdb.arch/amd64-disp-step.exp: add into rcx: send_signal=off:
>> verify_regs: rdi expected value
>> jump test_rip_rcx
>> Continuing at 0x4015b2.
>> 
>> Program terminated with signal SIGALRM, Alarm clock.
>> The program no longer exists.
>> [...]
>> [Current inferior is 1 [<null>]
>> (/vol/obj/gnu/gdb/gdb/11.4-amd64-dist/gdb/testsuite/outputs/gdb.arch/amd64-disp-step/amd64-disp-step)]
>> 
>> lib/gdb.exp (get_inferior_pid) turns this <null> into -1:
>> 
>
> I'm not exactly sure what is the particular problem triggering what you're seeing, but I observe a couple things:
>
> #1 - Solaris doesn't support displaced stepping.  It could, the x86-64 gdbarch displaced step implementation is pretty generic.
> But they're only installed on Linux today.  That's because displaced stepping is more useful with non-stop, and Solaris doesn't
> support that.

TBH, given the miserable state of the Solaris port (3000+ failures), I
haven't even looked into what features it is missing.  Unless the basis
is solid, there's probably not much point in that.

> However, I tweaked the testcase to force displaced-stepping off, with:
>
>     -gdb_test "set displaced-stepping on" ""
>     +gdb_test "set displaced-stepping off" ""
>
> and the test still passes cleanly on Linux.  So that shouldn't itself be a problem.  GDB will just do the
> regular remove-breakpoint, step, re-insert breakpoint dance on Solaris.

What had me wondering is this snippet in the test's gdb.log:

(gdb) PASS: gdb.arch/amd64-disp-step.exp: add into rcx: send_signal=off: verify_regs: rdi expected value
jump test_rip_rcx
Continuing at 0x401579.

Program terminated with signal SIGALRM, Alarm clock.
The program no longer exists.
(gdb) FAIL: gdb.arch/amd64-disp-step.exp: add into rcx: send_signal=on: jump back to test_rip_rcx
[...]
(gdb) set $rdi = 0
No registers.
(gdb) inferior
[Current inferior is 1 [<null>] (/vol/obj/gnu/gdb/gdb/11.4-amd64-dist/gdb/testsuite/outputs/gdb.arch/amd64-disp-step/outputs/gdb.arch/amd64-disp-step/amd64-disp-step)]
(gdb) FAIL: gdb.arch/amd64-disp-step.exp: add into rcx: send_signal=on: get inferior pid
Executing on target: kill -ALRM -1    (timeout = 300)
builtin_spawn -ignore SIGHUP kill -ALRM -1

  I really don't know where the first kill -ALRM is coming from.  In
  amd64-disp.step.exp (rip_test), the run for rcx with signal_modes=off
  succeeds, as does the jump to test_rip_rcx.

  On the next iteration, with signal_modes=on, however, before set_regs
  even started, the SIGALRM arrives (which should happen only *after*
  the set_regs IIUC), kills the inferior, and causes the -1
  inferior_pid.

  Quite weird unless I'm fundamentally misunderstanding something
  (highly probable).

> #2 - I did notice however something else.  The .S file has this:
>
>  /* test syscall */
>
> 	.global test_syscall
> 	mov $0x27,%eax /* getpid */
>  test_syscall:
> 	syscall
> 	nop
>  test_syscall_end:
> 	nop
>
> That seems like it is assuming Linux syscalls?  Or is 0x27 getpid on Solaris as well?  If not, I wouldn't
> be surprised if that syscall is doing something undefined.  Wonder what happens if you comment out that
> code and the corresponding test in the .exp file.

0x27 is SYS_pgrpsys on Solaris, with subcodes for the likes of getpgrp,
setpgrp etc.  However, disabling both test and code doesn't make a
difference for the overall outcome of the test.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University