From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 6A5A73858D28 for ; Mon, 30 Oct 2023 09:46:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6A5A73858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 6A5A73858D28 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698659164; cv=none; b=rVUJSCE/pF4qRKH6tcAfaM/HSp3CeMrXxWlV7swkvBAavI8ui5bTE7SDiLIl0v9T9wuw6Vga93bYY9zc7kD01XTN3uYLTN+7gm7YAIQ8vhLmjOSvQatLf66xeWOu5nz7MKSqdcof4/n/3LvJD1XTApBSx/f6H0myqJSJLJQNWxY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698659164; c=relaxed/simple; bh=1/LV+tPwEuZoJiFGtEmakU1ZQeNKHPJFSiaF+8d26WU=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=xyw3/oaNdqHStW0PzuWmUZn5FytMcZ02rOTD5KnkBTlXSM6+8d2qEbC0u3LXqi6pnI8vqpgqXZLdN7VuWYAgdS/3s1kDQVR7nqkRV3x3M3MVaDSyWhbML2h9T2BUusBkYKt5Q7Iw6LNXbojGokKbmRqZYjbWKx2aaNl8g3a839o= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1698659163; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=bEv/fQAXbOc0ibhSWHoD6wCc7ur9HcC9zUthiGHxFP8=; b=PaVheJ1/1/fnBdq4DRf3V1y455wHxf9WJtBGiEP68VUhBim96E38kbLodLzrYiryiEVALQ L/WzV4moUHysUCKeEL1NUPaoZAT/60VfDFyTdi06GKih9XWt+Ui/81QbvSQU2EmBgY2gxo lqH+1TROTX4ngRBvS/X9CzVt+o3tk0k= Received: from mail-ed1-f70.google.com (mail-ed1-f70.google.com [209.85.208.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-158-nleM5b-dMMSceMbLTxJH5g-1; Mon, 30 Oct 2023 05:46:01 -0400 X-MC-Unique: nleM5b-dMMSceMbLTxJH5g-1 Received: by mail-ed1-f70.google.com with SMTP id 4fb4d7f45d1cf-53ee9f409a9so3165406a12.1 for ; Mon, 30 Oct 2023 02:46:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698659160; x=1699263960; h=mime-version:message-id:date:references:in-reply-to:subject:to:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=bEv/fQAXbOc0ibhSWHoD6wCc7ur9HcC9zUthiGHxFP8=; b=hSEiLzVPOPGPTFW/NiarMlVv39GBH9kKLQBVaL+zn3VvBt3ZuEh1PRJSwDB596m28p AjZabzUXki9RBHUBQlr30bm3+Km5CYet8eZYoYi/dqVo+ubkVQphoN7QcIoM7ggSA4lF rh+Pq79N7d2fUgFP6Z7W2vjS5Pc2YJGJ1pjLFB+Dh66sGHeQMO11DRgKy/XJBxM+2Mp/ Itz+FEPtM/Eeb2ABj9jN1yLH1MfaBfaIITvWkC31cFVuQKYiPoT7e7vNzCPo37y/rqWN 4TizbmhrYY/zeh4Cslq/173w0joTqocmo9vYbqXeGwI0bvb65jCv9GIXx6+f6KuNQJUM OmEQ== X-Gm-Message-State: AOJu0YwIBEPRGoL/5w//qdbtefV5DaiH2lRWvDHNCTyRAwGz7Z459ogl tPVUZlofbJviNGmUoJjKXn9hxocoA5wCtQkRCs1dg4m7k1YAQi0ejdui88P68Wjbq26XKrwsqbr mYgMcWeUqybcz13uF3F7YsQ== X-Received: by 2002:a05:6402:229a:b0:541:875:53d8 with SMTP id cw26-20020a056402229a00b00541087553d8mr6464331edb.23.1698659160751; Mon, 30 Oct 2023 02:46:00 -0700 (PDT) X-Google-Smtp-Source: AGHT+IG4q7FODqiVQejCVavh6WEcQOkzPGPYczudqZ2YNao4ivkn9iSqwVhOcmq8KPNZkOXo1gACeQ== X-Received: by 2002:a05:6402:229a:b0:541:875:53d8 with SMTP id cw26-20020a056402229a00b00541087553d8mr6464319edb.23.1698659160349; Mon, 30 Oct 2023 02:46:00 -0700 (PDT) Received: from localhost ([31.111.84.209]) by smtp.gmail.com with ESMTPSA id r27-20020a50d69b000000b00537666d307csm5943934edi.32.2023.10.30.02.45.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Oct 2023 02:45:59 -0700 (PDT) From: Andrew Burgess To: Ulrich Weigand , "gdb-patches@sourceware.org" , "cel@linux.ibm.com" , Keith Seitz Subject: RE: [PATCH 1/2, ver2] PowerPC, Fix-test-gdb.base-store.exp In-Reply-To: <51fbddb2f868c778660c592a91c39677a3763197.camel@de.ibm.com> References: <6f9c8fa20962129048384d74f6f15d1b37d255ed.camel@us.ibm.com> <76b8ed7b93608d40ab42b0538319f78eaf7d621c.camel@us.ibm.com> <87bkcyhc5g.fsf@redhat.com> <8735bded66303c8cdfacfad9bd953c582e8076f2.camel@linux.ibm.com> <87sf602wqt.fsf@redhat.com> <51fbddb2f868c778660c592a91c39677a3763197.camel@de.ibm.com> Date: Mon, 30 Oct 2023 09:45:58 +0000 Message-ID: <87ttq81m09.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Ulrich Weigand writes: > Andrew Burgess wrote: > >>Sorry for being such a pain w.r.t. this patch. Honestly, it's mostly >>because you touched infrun.c that I'm so interested here. > [...] >>And I'd like to see clearer details about which tests the infrun.c >>changes will fix. > > Hi Andrew, as I suggested that particular infrun.c change > to Carl, let me add some background to what Carl replied. > > This one-line change in infrun.c fixes a (potential) common-code > bug in existing code. However, this bug is likely dormant on > all current platforms: > > First of all, the bug only shows up on platforms where the > kernel uses a trampoline to dispatch *calls to* the signal > handler (not just *returns from* the signal handler). Many > platforms use a trampoline for signal return, and that is > working fine, but the only platform I'm aware of that uses > a trampoline for signal handler calls is (recent kernels for) > PowerPC. I believe the rationale for using a trampoline here > is to improve performance by avoiding unbalancing of the > branch predictor's call/return stack. > > However, on PowerPC the bug is dormant as well as it is hidden > by *another* bug that prevents correct unwinding out of the > signal trampoline. This is because the custom CFI for the > trampoline uses a register number (VSCR) that is not ever used > by compiler-generated CFI, and that particular register is > mapped to an invalid number by the current PowerPC DWARF > mapper. Ulrich, Thanks for the great explanation. I think adding this to the commit message would be a great improvement. But also, you said: > Now, as Carl fixed the PowerPC DWARF mapper to fix some test > case regressions that showed up on POWER10, he added correct > mappings for all registers including VSCR. This then caused > unwinding out of the signal trampoline to start working > correctly, which in turn exposed the pre-existing infrun.c bug > in handling signal call trampolines. As part of the commit message at this point I'd like to see the name of at least one (if the number is small, I'd list them all though) test(s) that required this change in order to keep working correctly. Often, when I end up looking at old commits in the history, I want to know, what is an example of something that this change actually fixes, and it's super frustrating when I have to try and figure this information out for myself -- given that it must have been known at commit time. > > Now, that particular bug is that if the kernel uses a signal > call trampoline, infrun.c will see that the current PC is > in a frame that is an immediate child of the step frame (as > the trampoline frame unwinds to the step frame) - and then > incorrectly thinks that a *subroutine call* must have happened. > But we don't want to treat a signal handler invocation like > a subroutine call, in particular we want "nexti" to step > into it. That's fixed by the one-line change. Thanks, Andrew