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 CCA233858D32 for ; Mon, 16 Oct 2023 14:31:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CCA233858D32 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 CCA233858D32 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=1697466690; cv=none; b=uvYzqrX9rvnunI8q2bFEcpWDnvlHYOWnlCEG5PbQfUXcPDMKihuYJd4KWRY/etb6LffSDAlv96ZNU7jIdcFbcanEPgZCEz6ZMB+7g66EMZ0FtY3zwGEtIWKgzMsz0YZeXRp3eEZgW7l3lsm5d07ow418BFxrdwubHsoNlSExe7c= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1697466690; c=relaxed/simple; bh=Uv57DJzzla8iqnaoFqpRtEWyrhZC0/X7vJAvcY0LvXA=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=qBfWpQIC00dUN/ffKY0zB6Zei0enaxnNi46+BhCPMxPwQZWTvGoJnkma3lqTs5tGZD6RsPyccomrVoJqBfCZMykIG4x8vyyME5E855LHY+hlG+dRHtvJXcbS6z/L0t44GEKhdl6mmS5liI6iJxV662cfN/a6l39e4of3C+LAD2c= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1697466688; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=n1b001eZNFIbVrsZ40u3fvQOGwZI9+l8VsaP+g1fS4c=; b=SF2l67FOzelKsD39RKOAAp9zmwV/R2b4wJNLz31QEX/5SkPqt1+gD8D3GvJq6Y8QCxu+aD ryvABnfqUpwE63j0tExNboV9bA+9I6bnJzqTWAlZOTu1ij7c/zM+V1eEJE6qj7/bAMBKlJ DS9SJZlXkNxVcbb7HJi3B/TgyZj9D6k= Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-330-EJ0lzP7mMSaRKTVApmag7Q-1; Mon, 16 Oct 2023 10:31:27 -0400 X-MC-Unique: EJ0lzP7mMSaRKTVApmag7Q-1 Received: by mail-qk1-f199.google.com with SMTP id af79cd13be357-7740c3506b9so587578885a.0 for ; Mon, 16 Oct 2023 07:31:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697466686; x=1698071486; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=n1b001eZNFIbVrsZ40u3fvQOGwZI9+l8VsaP+g1fS4c=; b=GjisJ75isDYmCOLehV9aCi8Qx3n2Jn6/Scd3SBVYbJDd9NCR0DRFyfVwwEsh6mxkrN SDmJL7o2xQ+ehE1/+nHbS40StLj0gYvFB1eIdQG76zkQLq0HNHoRhBrsmDr44nlsCk+G BH476xaBrP1ReQ/lOyWTcMqgBSDZn8sxAhS2U2HQMKGRejyfGUjmnggsFctrJCJ0EE3N 1URWaB25ZZvBisv4lwvw/wY2u8h2MKwJIkVK0s9YyghRiU1VfqrYmGSmARe3asdd5JRU soP3IP0xScxXTFv2Y5LSG7E4BkGTV83VUIp/uvbJhbQgYMcYMLbeW0TglCjdBdlSQP3B PfjA== X-Gm-Message-State: AOJu0YyD+1QExvavIhwJBBp+7u5N0mtRajVkimGPQrfwZcwv8KI5rO3l U/O1ZvbF3cNMeHi9fmXmd7AyaOIcYQb/0YJmP5XyP+kSe5kKLe/3Ixl8SkmjrqkTGoxCKauNlGK fvoWuHXV18UeZaDRAUV2mG3kugvEPdA== X-Received: by 2002:a05:620a:b5b:b0:774:16c3:bf2b with SMTP id x27-20020a05620a0b5b00b0077416c3bf2bmr35863938qkg.50.1697466686165; Mon, 16 Oct 2023 07:31:26 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEhSu7QNkVlOQcXcJbooLl+3aDbfSuc2G5/UyMwEOplTudtirkqmT+jua9wuaS2d+dSlucMIA== X-Received: by 2002:a05:620a:b5b:b0:774:16c3:bf2b with SMTP id x27-20020a05620a0b5b00b0077416c3bf2bmr35863921qkg.50.1697466685843; Mon, 16 Oct 2023 07:31:25 -0700 (PDT) Received: from localhost ([31.111.84.209]) by smtp.gmail.com with ESMTPSA id vq25-20020a05620a559900b0076f35d17d06sm3023613qkn.69.2023.10.16.07.31.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Oct 2023 07:31:25 -0700 (PDT) From: Andrew Burgess To: Carl Love , gdb-patches@sourceware.org, UlrichWeigand Cc: cel@us.ibm.com Subject: Re: [Patch 1/2] PowerPC, Fix-test-gdb.base-store.exp In-Reply-To: <76b8ed7b93608d40ab42b0538319f78eaf7d621c.camel@us.ibm.com> References: <6f9c8fa20962129048384d74f6f15d1b37d255ed.camel@us.ibm.com> <76b8ed7b93608d40ab42b0538319f78eaf7d621c.camel@us.ibm.com> Date: Mon, 16 Oct 2023 15:31:23 +0100 Message-ID: <87bkcyhc5g.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=-10.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RCVD_IN_SORBS_WEB,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: Carl Love writes: > GDB maintainers: > > This is the first patch in the series which fixes the DWWARF register > mapping and signal handling issues on PowerPC. > > Carl > > ----------------------------------------------- > > rs6000, Fix Linux DWARF register mapping > > The PowerPC DWARF register mapping is the same for the .eh_frame and > .debug_frame on Linux. PowerPC uses different mapping for .eh_frame and > .debug_frame on other operating systems. The current GDB support for > mapping the DWARF registers in rs6000_linux_dwarf2_reg_to_regnum and > rs6000_adjust_frame_regnum file gdb/rs6000-tdep.c is not correct for Linux. > The files have some legacy mappings for spe_acc, spefscr, EV which was > removed from GCC in 2017. > > This patch adds a two new functions rs6000_linux_dwarf2_reg_to_regnum, > and rs6000_linux_adjust_frame_regnum in file gdb/ppc-linux-tdep.c to handle > the DWARF register mappings on Linux. Function > rs6000_linux_dwarf2_reg_to_regnum is installed for both gdb_dwarf_to_regnum > and gdbarch_stab_reg_to_regnum since the mappings are the same. > > The ppc_linux_init_abi function in gdb/ppc-linux-tdep.c is updated to > call set_gdbarch_dwarf2_reg_to_regnum map the new function > rs6000_linux_dwarf2_reg_to_regnum for the architecture. Similarly, > dwarf2_frame_set_adjust_regnum is called to map > rs6000_linux_adjust_frame_regnum into the architecture. > > The second issue fixed by this patch is the check for subroutine > process_event_stop_test. Need to make sure the frame is not the > SIGTRAMP_FRAME. The sequence of events on most platforms is: Usually for GDB we avoid bundling unrelated changes into a single commit. Each commit should address one self contained issue (as far as possible). I really struggling to see any connection between the two fixes you have here. > > 1) Some code is running when a signal arrives. > 2) The kernel handles the signal and dispatches to the handler. > ... > > However on PowerPC the sequence of events is: > > 1) Some code is running when a signal arrives. > 2) The kernel handles the signal and dispatches to the trampoline. > 3) The trampoline performs a normal function call to the handler. > ... > > We want "nexti" to step into, not over, signal handlers invoked > by the kernel. This is the case most platforms as the kernel puts a > signal trampoline frame onto the stack to handle proper return after the > handler. However, on some platforms such as PowerPC, the kernel actually > uses a trampoline to handle *invocation* of the handler. > > The issue is fixed in function process_event_stop_test by adding a check > that the frame is not a SIGTRAMP_FRAME to the if statement to stop in > a subroutine call. This prevents GDB from erroneously detecting the > trampoline invocation as a subroutine call. > > This patch fixes two regression test failures in gdb.base/store.exp. It > also fixes two regression failures in gdb.python/py-thread-exited.exp. On the one random PPC box I tried this patch on, I'm not seeing any failures in gdb.python/py-thread-exited.exp either before, or after this commit. Which tests in gdb.python/py-thread-exited.exp are you seeing as broken? And which of the two fixes in this commit fix the problems you're seeing? > > Patch has been tested on Power 8 LE/BE, Power 9 LE/BE, Power 10 with no > new regressions. > --- > gdb/infrun.c | 13 ++++++++++ > gdb/ppc-linux-tdep.c | 56 ++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 69 insertions(+) > > diff --git a/gdb/infrun.c b/gdb/infrun.c > index 4730d290442..922d8a6913d 100644 > --- a/gdb/infrun.c > +++ b/gdb/infrun.c > @@ -7334,8 +7334,21 @@ process_event_stop_test (struct execution_control_state *ecs) > initial outermost frame, before sp was valid, would > have code_addr == &_start. See the comment in frame_id::operator== > for more. */ > + > + /* We want "nexti" to step into, not over, signal handlers invoked > + by the kernel, therefore this subroutine check should not trigger > + for a signal handler invocation. On most platforms, this is already > + not the case, as the kernel puts a signal trampoline frame onto the > + stack to handle proper return after the handler, and therefore at this > + point, the current frame is a grandchild of the step frame, not a > + child. However, on some platforms, the kernel actually uses a > + trampoline to handle *invocation* of the handler. In that case, > + when executing the first instruction of the trampoline, this check > + would erroneously detect the trampoline invocation as a subroutine > + call. Fix this by checking for SIGTRAMP_FRAME. */ > if ((get_stack_frame_id (frame) > != ecs->event_thread->control.step_stack_frame_id) > + && get_frame_type (frame) != SIGTRAMP_FRAME > && ((frame_unwind_caller_id (get_current_frame ()) > == ecs->event_thread->control.step_stack_frame_id) > && ((ecs->event_thread->control.step_stack_frame_id > diff --git a/gdb/ppc-linux-tdep.c b/gdb/ppc-linux-tdep.c > index 784dafa59db..7fb90799dff 100644 > --- a/gdb/ppc-linux-tdep.c > +++ b/gdb/ppc-linux-tdep.c > @@ -83,6 +83,7 @@ > #include "features/rs6000/powerpc-isa207-vsx64l.c" > #include "features/rs6000/powerpc-isa207-htm-vsx64l.c" > #include "features/rs6000/powerpc-e500l.c" > +#include "dwarf2/frame.h" > > /* Shared library operations for PowerPC-Linux. */ > static struct target_so_ops powerpc_so_ops; > @@ -2088,6 +2089,52 @@ ppc_linux_displaced_step_prepare (gdbarch *arch, thread_info *thread, > return per_inferior->disp_step_buf->prepare (thread, displaced_pc); > } > > +/* Convert a Dwarf 2 register number to a GDB register number for Linux. */ > +static int > +rs6000_linux_dwarf2_reg_to_regnum (struct gdbarch *gdbarch, int num) > +{ > + ppc_gdbarch_tdep *tdep = gdbarch_tdep(gdbarch); > + > + if (0 <= num && num <= 31) > + return tdep->ppc_gp0_regnum + num; > + else if (32 <= num && num <= 63) > + /* FIXME: jimb/2004-05-05: What should we do when the debug info > + specifies registers the architecture doesn't have? Our > + callers don't check the value we return. */ I see this comment was just copied from else where, but isn't the answer just: return -1 ? The comment about the 'return -1' at the trail of this function seems to suggest that would be the correct thing to do. I guess I'm asking: do we need to add another copy of this (I think out of date) fixme? Thanks, Andrew > + return tdep->ppc_fp0_regnum + (num - 32); > + else if (77 <= num && num < 77 + 32) > + return tdep->ppc_vr0_regnum + (num - 77); > + else > + switch (num) > + { > + case 65: > + return tdep->ppc_lr_regnum; > + case 66: > + return tdep->ppc_ctr_regnum; > + case 76: > + return tdep->ppc_xer_regnum; > + case 109: > + return tdep->ppc_vrsave_regnum; > + case 110: > + return tdep->ppc_vrsave_regnum - 1; /* vscr */ > + } > + > + /* Unknown DWARF register number. */ > + return -1; > +} > + > +/* Translate a .eh_frame register to DWARF register, or adjust a > + .debug_frame register. */ > + > + > +static int > +rs6000_linux_adjust_frame_regnum (struct gdbarch *gdbarch, int num, > + int eh_frame_p) > +{ > + /* Linux uses the same numbering for .debug_frame numbering as .eh_frame. */ > + return num; > +} > + > static void > ppc_linux_init_abi (struct gdbarch_info info, > struct gdbarch *gdbarch) > @@ -2135,6 +2182,15 @@ ppc_linux_init_abi (struct gdbarch_info info, > set_gdbarch_stap_is_single_operand (gdbarch, ppc_stap_is_single_operand); > set_gdbarch_stap_parse_special_token (gdbarch, > ppc_stap_parse_special_token); > + /* Linux DWARF register mapping is different from the othe OS's. */ > + set_gdbarch_dwarf2_reg_to_regnum (gdbarch, > + rs6000_linux_dwarf2_reg_to_regnum); > + /* Note on Linux the mapping for the DWARF registers and the stab registers > + use the same numbers. Install rs6000_linux_dwarf2_reg_to_regnum for the > + stab register mappings as well. */ > + set_gdbarch_stab_reg_to_regnum (gdbarch, > + rs6000_linux_dwarf2_reg_to_regnum); > + dwarf2_frame_set_adjust_regnum (gdbarch, rs6000_linux_adjust_frame_regnum); > > if (tdep->wordsize == 4) > { > -- > 2.37.2