From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) by sourceware.org (Postfix) with ESMTPS id 5E5083858CD1 for ; Fri, 14 Jul 2023 17:25:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5E5083858CD1 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-3fbd33a57b6so21377555e9.2 for ; Fri, 14 Jul 2023 10:25:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689355542; x=1691947542; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=W3ItZSIDQKpZqZMPr+6pehD42TpiabM6YtGJOQgC6xs=; b=kEkmUAC3LiGQ8FeCgJh/mG5gC+8Ff+b2kqFPjz05a7xtd7/F29R/jjuJWeMHEXrQph 9hzxRAOrKuSHr8KyaP3mojN1hdhJem+EX3JSuIw+JmPivev1A3dQ2AbbVy384NuVKvZn Dm8Uafpm8N15Cr16D6wAKYxzP1KnxLwT+0v5Um1ivibRg0pbauBbSciF9k0RbcKs5qWq CMf0icPEcnizD/0PwN6b1Szj3wTrdx60rlr34nBzlHJFQc0EBygnGbNpPZHg1fzxS6fr 6OCNDlIuL5YkJRFiZHzPNQ91LtZq6MFE8f6Q4wfcxMs6HPoBrH6bSmUiRDAxDxcncqOk Zr4w== X-Gm-Message-State: ABy/qLY8yjEZOwvJ/59b2p/rLyqSdWVhT3BHEMBLdkrSXbgM0RoP24Lu +kmNgSyxO0bb1GlC3IC5StM= X-Google-Smtp-Source: APBJJlEEWvUfSn/8Or3KZijbO8u2cHY5gdSBfOjybMTUO9Fis3kLpvIkktQrQ5BqQmiRflUh6k839A== X-Received: by 2002:a5d:6183:0:b0:316:ecd9:aa3c with SMTP id j3-20020a5d6183000000b00316ecd9aa3cmr3399040wru.5.1689355542397; Fri, 14 Jul 2023 10:25:42 -0700 (PDT) Received: from ?IPV6:2001:8a0:f91d:bc00:98b3:dfb7:8070:8955? ([2001:8a0:f91d:bc00:98b3:dfb7:8070:8955]) by smtp.gmail.com with ESMTPSA id o6-20020a5d4a86000000b0030e5bd253aasm11304976wrq.39.2023.07.14.10.25.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 14 Jul 2023 10:25:41 -0700 (PDT) Message-ID: Date: Fri, 14 Jul 2023 18:25:40 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [PATCH] Guard against killing unrelated processes in amd64-disp-step.exp Content-Language: en-US To: Rainer Orth , Tom Tromey Cc: gdb-patches@sourceware.org, Andrew Burgess References: <87cz0vpy7g.fsf@tromey.com> From: Pedro Alves In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 2023-07-13 18:59, Rainer Orth wrote: > Hi Tom, > >>>>>>> "Rainer" == Rainer Orth writes: >> >> Rainer> When testing current gdb trunk on Solaris/amd64, the whole session was >> Rainer> reliably terminated by make check. I could trace this to the following >> Rainer> entry in gdb.arch/amd64-disp-step/gdb.log: >> >> Thank you for the patch. >> >> Rainer> If $inferior_pid doesn't refer a single process for some reason, this >> Rainer> kill would terminate either a process group or the whole session. >> >> I don't mind the patch, it seems like an improvement -- but I wonder why Agreed. This is the second time all these years that I'm seeing something like this. ISTR some test killing everything on OpenBSD many years ago. :-) > > 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 [] (/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 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. 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. #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. Pedro Alves