From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by sourceware.org (Postfix) with ESMTPS id 9AD583850429 for ; Fri, 4 Dec 2020 01:54:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9AD583850429 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=alves.ped@gmail.com Received: by mail-wr1-f68.google.com with SMTP id k14so3811305wrn.1 for ; Thu, 03 Dec 2020 17:54:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=O42bBfB3ShErDL0JG/AYjgljbuUfq+gNya8Laggd3uM=; b=TZSv3Sidu4DIrTmzMINrvMRsXB4pfEpIyAvDaOUfkV1V+AXMOcd0cVH3pRxvLRan+r pnWGNrZYV+Ediwe6QI/HFm3Iaf/HE46HHJkEo6YYfCjZuipV8lu1rVQGZFR/C304cMF5 UhzWkKkw65xP8dAEO/lLqhUjie6UTXPOHT6W5Xkg7cLDnhhadgwf5oB45bMIvEOIh81w LZz9DoaULEP+9OvYYCgTsRJCftdERrqATqJKHxwtCVy2vDIDzBUt3+1M30Xx5pi4jROW 5+QIQSIlv/yRqm4YBsWPBE1yM4dAIqvyK/6CMm3p4LrMgH3seNpIEnjyXLVxZU4yeiUF Pc/Q== X-Gm-Message-State: AOAM532zjV6OIs3V0Bq1cmIOEwcYlKhGJdMceWwNT2NeuNrtnjwvwZYb 10tIDsO+F+y9zIQlqbtMmxp9cVkdbepIBg== X-Google-Smtp-Source: ABdhPJx89h4Ir4mMe3IVSMjRBPp88nahzJSZSiIBTga4zsDODOqY19GyYqprwXUwIzjzMoyeY4IM+Q== X-Received: by 2002:adf:f783:: with SMTP id q3mr2140210wrp.88.1607046848725; Thu, 03 Dec 2020 17:54:08 -0800 (PST) Received: from ?IPv6:2001:8a0:f91f:e900:1d90:d745:3c32:c159? ([2001:8a0:f91f:e900:1d90:d745:3c32:c159]) by smtp.gmail.com with ESMTPSA id p3sm1453171wrs.50.2020.12.03.17.54.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Dec 2020 17:54:07 -0800 (PST) Subject: Re: [PATCH v2 02/14] gdb: clear inferior displaced stepping state and in-line step-over info on exec To: Simon Marchi , Simon Marchi , gdb-patches@sourceware.org References: <20201202154805.1484317-1-simon.marchi@polymtl.ca> <20201202154805.1484317-3-simon.marchi@polymtl.ca> <8d5cc52e-79c0-d1a5-6544-f7fdd28a6005@simark.ca> Cc: Simon Marchi From: Pedro Alves Message-ID: Date: Fri, 4 Dec 2020 01:54:06 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <8d5cc52e-79c0-d1a5-6544-f7fdd28a6005@simark.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.3 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 autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2020 01:54:11 -0000 On 12/2/20 5:16 PM, Simon Marchi wrote: > On 2020-12-02 10:47 a.m., Simon Marchi via Gdb-patches wrote: >> From: Simon Marchi >> Add a test with a program with two threads that does an exec. The test >> includes the following axis: >> >> - whether it's the leader thread or the other thread that does the exec. >> >> - whether the exec'r and exec'd program have different text segment >> addresses. This is to hopefully catch cases where the displaced >> stepping info doesn't get reset, and GDB later tries to restore bytes >> of the old address space in the new address space. If the mapped >> addresses are different, we should get some memory error. This >> happens without the patch applied: >> >> $ ./gdb -q -nx --data-directory=data-directory testsuite/outputs/gdb.threads/step-over-exec/step-over-exec-execr-thread-leader-diff-text-segs-true -ex "b main" -ex r -ex "b my_execve_syscall if 0" -ex "set displaced-stepping on" >> ... >> Breakpoint 1, main (argc=1, argv=0x7fffffffde38) at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.threads/step-over-exec.c:69 >> 69 argv0 = argv[0]; >> Breakpoint 2 at 0x60133a: file /home/simark/src/binutils-gdb/gdb/testsuite/lib/my-syscalls.S, line 34. >> (gdb) c >> Continuing. >> [New Thread 0x7ffff7c62640 (LWP 1455423)] >> Leader going in exec. >> Exec-ing /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-over-exec/step-over-exec-execr-thread-leader-diff-text-segs-true-execd >> [Thread 0x7ffff7c62640 (LWP 1455423) exited] >> process 1455418 is executing new program: /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-over-exec/step-over-exec-execr-thread-leader-diff-text-segs-true-execd >> Error in re-setting breakpoint 2: Function "my_execve_syscall" not defined. >> No unwaited-for children left. >> (gdb) n >> Single stepping until exit from function _start, >> which has no line number information. >> Cannot access memory at address 0x6010d2 >> (gdb) >> >> - Whether displaced stepping is allowed or not, so that we end up >> testing both displaced stepping and in-line stepping on arches that do >> support displaced stepping (otherwise, it just tests in-line stepping >> twice I suppose) > > Just to let you know, I forgot to run the test on > native-gdbserver/native-extended-gdbserver. I get some failures due to > a GDBserver internal error: > > /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:3665: A problem internal to GDBserver has been detected. > ptid_t linux_process_target::wait_1(ptid_t, target_waitstatus*, target_wait_flags): Assertion `step_over_bkpt == null_ptid' failed. Can we kfail it? It sounds like the kind of thing that would happen if gdbserver forgets to clear step_over_bkpt when the process execs.