Message ID | 20190113014248.28071-1-jcmvbkbc@gmail.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 2424 invoked by alias); 13 Jan 2019 01:43:05 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 2409 invoked by uid 89); 13 Jan 2019 01:43:05 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.4 required=5.0 tests=BAYES_00, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, HK_RANDOM_ENVFROM, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-lj1-f194.google.com Received: from mail-lj1-f194.google.com (HELO mail-lj1-f194.google.com) (209.85.208.194) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 13 Jan 2019 01:43:03 +0000 Received: by mail-lj1-f194.google.com with SMTP id k15-v6so16033820ljc.8 for <gdb-patches@sourceware.org>; Sat, 12 Jan 2019 17:43:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=MYo4kbj3u7zqWlHzdEBdyVmOVDiEUi+gab3y2dMmlyA=; b=DdfsNDv0ytZinn6Px+00M2gyusTaTBjZyGtUJXC/kX/nNbAfH2XzAfHFn4j/03yOeX /3qWjOOt6pAvvUBG8og+eo70NB8ezfAfL4MqqXtF4hOu1HTynQenWMsaEIfBxSstBc1W QFdRtxdZSZH6Ripwz+wDxNVFvP2yPxKyr7KrH43arwKCD7YmLLt+cNl123iE/LMaScJS Dm0kDDwptybSeBxfAlCS/m39H5ardn41Oq9ohCM3bkg8RPFXF5h6mHCkD6sBpHRkNxPJ /EDo3fEC/s3hLJ9q9A8/0mV+mub730cqyhzX6BlVlFA10rXl02yQuRW/dIARcjBnGTzu zteg== Return-Path: <jcmvbkbc@gmail.com> Received: from octofox.hsd1.ca.comcast.net. (jcmvbkbc-1-pt.tunnel.tserv24.sto1.ipv6.he.net. [2001:470:27:1fa::2]) by smtp.gmail.com with ESMTPSA id r203sm11285644lff.13.2019.01.12.17.42.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 12 Jan 2019 17:42:59 -0800 (PST) From: Max Filippov <jcmvbkbc@gmail.com> To: gdb-patches@sourceware.org Cc: Woody LaRue <larue@cadence.com>, Max Filippov <jcmvbkbc@gmail.com> Subject: [PATCH RESEND] gdb: xtensa: fix register counters for xtensa-linux Date: Sat, 12 Jan 2019 17:42:48 -0800 Message-Id: <20190113014248.28071-1-jcmvbkbc@gmail.com> X-IsSubscribed: yes |
Commit Message
Max Filippov
Jan. 13, 2019, 1:42 a.m. UTC
Commit 37d9e0623102 ("gdb: xtensa: handle privileged registers") changed how the tdep->num_regs and tdep->num_pseudo_regs are calculated, but didn't update these numbers in the gdbarch for the xtensa-linux target. As a result xtensa-linux-gdb behaves as xtensa-elf-gdb and cannot communicate with the linux gdbserver. Fix tdep->num_pseudo_regs calculation and call set_gdbarch_num_regs and set_gdbarch_num_pseudo_regs in xtensa_linux_init_abi. gdb/ 2018-11-16 Max Filippov <jcmvbkbc@gmail.com> * xtensa-linux-tdep.c (xtensa_linux_init_abi): Update tdep->num_pseudo_regs. Add calls to set_gdbarch_num_regs and set_gdbarch_num_pseudo_regs. --- gdb/xtensa-linux-tdep.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
Comments
On 2019-01-12 8:42 p.m., Max Filippov wrote: > Commit 37d9e0623102 ("gdb: xtensa: handle privileged registers") changed > how the tdep->num_regs and tdep->num_pseudo_regs are calculated, but > didn't update these numbers in the gdbarch for the xtensa-linux target. > As a result xtensa-linux-gdb behaves as xtensa-elf-gdb and cannot > communicate with the linux gdbserver. > Fix tdep->num_pseudo_regs calculation and call set_gdbarch_num_regs and > set_gdbarch_num_pseudo_regs in xtensa_linux_init_abi. > > gdb/ > 2018-11-16 Max Filippov <jcmvbkbc@gmail.com> > > * xtensa-linux-tdep.c (xtensa_linux_init_abi): Update > tdep->num_pseudo_regs. Add calls to set_gdbarch_num_regs and > set_gdbarch_num_pseudo_regs. > --- > gdb/xtensa-linux-tdep.c | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/gdb/xtensa-linux-tdep.c b/gdb/xtensa-linux-tdep.c > index 1764b953a00b..796143c6699b 100644 > --- a/gdb/xtensa-linux-tdep.c > +++ b/gdb/xtensa-linux-tdep.c > @@ -101,7 +101,13 @@ xtensa_linux_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch) > struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch); > > if (tdep->num_nopriv_regs < tdep->num_regs) > - tdep->num_regs = tdep->num_nopriv_regs; > + { > + tdep->num_pseudo_regs += tdep->num_regs - tdep->num_nopriv_regs; > + tdep->num_regs = tdep->num_nopriv_regs; > + > + set_gdbarch_num_regs (gdbarch, tdep->num_regs); > + set_gdbarch_num_pseudo_regs (gdbarch, tdep->num_pseudo_regs); > + } > > linux_init_abi (info, gdbarch); > > Hi Max. I am just a bit puzzled by the num_pseudo_regs computation (especially the +=). Can you explain it quickly? Thanks, Simon
On Sat, Jan 12, 2019 at 9:56 PM Simon Marchi <simon.marchi@ericsson.com> wrote: > > On 2019-01-12 8:42 p.m., Max Filippov wrote: > > Commit 37d9e0623102 ("gdb: xtensa: handle privileged registers") changed > > how the tdep->num_regs and tdep->num_pseudo_regs are calculated, but > > didn't update these numbers in the gdbarch for the xtensa-linux target. > > As a result xtensa-linux-gdb behaves as xtensa-elf-gdb and cannot > > communicate with the linux gdbserver. > > Fix tdep->num_pseudo_regs calculation and call set_gdbarch_num_regs and > > set_gdbarch_num_pseudo_regs in xtensa_linux_init_abi. > > > > gdb/ > > 2018-11-16 Max Filippov <jcmvbkbc@gmail.com> > > > > * xtensa-linux-tdep.c (xtensa_linux_init_abi): Update > > tdep->num_pseudo_regs. Add calls to set_gdbarch_num_regs and > > set_gdbarch_num_pseudo_regs. > > --- > > gdb/xtensa-linux-tdep.c | 8 +++++++- > > 1 file changed, 7 insertions(+), 1 deletion(-) > > > > diff --git a/gdb/xtensa-linux-tdep.c b/gdb/xtensa-linux-tdep.c > > index 1764b953a00b..796143c6699b 100644 > > --- a/gdb/xtensa-linux-tdep.c > > +++ b/gdb/xtensa-linux-tdep.c > > @@ -101,7 +101,13 @@ xtensa_linux_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch) > > struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch); > > > > if (tdep->num_nopriv_regs < tdep->num_regs) > > - tdep->num_regs = tdep->num_nopriv_regs; > > + { > > + tdep->num_pseudo_regs += tdep->num_regs - tdep->num_nopriv_regs; > > + tdep->num_regs = tdep->num_nopriv_regs; > > + > > + set_gdbarch_num_regs (gdbarch, tdep->num_regs); > > + set_gdbarch_num_pseudo_regs (gdbarch, tdep->num_pseudo_regs); > > + } > > > > linux_init_abi (info, gdbarch); > > > > > > Hi Max. > > I am just a bit puzzled by the num_pseudo_regs computation (especially the +=). > Can you explain it quickly? In the original code (prior to 37d9e0623102) num_regs was the smallest of the number of the first pseudo register or the first privileged register, and num_pseudo_regs was the total number of registers minus num_regs. The register table is constructed so that pseudo registers are always at the end of it, so num_regs was always equal to num_nonpriv_regs. I'd like to restore this in xtensa-linux gdb, and what I do is I increase num_pseudo_regs by the difference of num_regs and num_nonpriv regs and set num_regs equal to num_nonpriv_regs to maintain the above equations.
On 2019-01-13 03:36, Max Filippov wrote: > In the original code (prior to 37d9e0623102) num_regs was the smallest > of > the number of the first pseudo register or the first privileged > register, and > num_pseudo_regs was the total number of registers minus num_regs. > The register table is constructed so that pseudo registers are always > at the > end of it, so num_regs was always equal to num_nonpriv_regs. > I'd like to restore this in xtensa-linux gdb, and what I do is I > increase > num_pseudo_regs by the difference of num_regs and num_nonpriv regs > and set num_regs equal to num_nonpriv_regs to maintain the above > equations. "num_regs == num_nonpriv_regs": is this only true for Linux, because we don't have access to privileged registers (and therefore there are 0 nonpriv registers)? For bare-metal, num_regs would be greater than num_nonpriv_regs? Simon -
On Sun, Jan 13, 2019 at 8:32 AM Simon Marchi <simon.marchi@polymtl.ca> wrote: > > On 2019-01-13 03:36, Max Filippov wrote: > > In the original code (prior to 37d9e0623102) num_regs was the smallest > > of > > the number of the first pseudo register or the first privileged > > register, and > > num_pseudo_regs was the total number of registers minus num_regs. > > The register table is constructed so that pseudo registers are always > > at the > > end of it, so num_regs was always equal to num_nonpriv_regs. > > I'd like to restore this in xtensa-linux gdb, and what I do is I > > increase > > num_pseudo_regs by the difference of num_regs and num_nonpriv regs > > and set num_regs equal to num_nonpriv_regs to maintain the above > > equations. > > "num_regs == num_nonpriv_regs": is this only true for Linux, because we > don't have access to privileged registers (and therefore there are 0 > nonpriv registers)? Correct. > For bare-metal, num_regs would be greater than num_nonpriv_regs? Correct.
On 2019-01-13 14:33, Max Filippov wrote: > On Sun, Jan 13, 2019 at 8:32 AM Simon Marchi <simon.marchi@polymtl.ca> > wrote: >> >> On 2019-01-13 03:36, Max Filippov wrote: >> > In the original code (prior to 37d9e0623102) num_regs was the smallest >> > of >> > the number of the first pseudo register or the first privileged >> > register, and >> > num_pseudo_regs was the total number of registers minus num_regs. >> > The register table is constructed so that pseudo registers are always >> > at the >> > end of it, so num_regs was always equal to num_nonpriv_regs. >> > I'd like to restore this in xtensa-linux gdb, and what I do is I >> > increase >> > num_pseudo_regs by the difference of num_regs and num_nonpriv regs >> > and set num_regs equal to num_nonpriv_regs to maintain the above >> > equations. >> >> "num_regs == num_nonpriv_regs": is this only true for Linux, because >> we >> don't have access to privileged registers (and therefore there are 0 >> nonpriv registers)? > > Correct. > >> For bare-metal, num_regs would be greater than num_nonpriv_regs? > > Correct. Ok. For the record, the patch LGTM, but I am not sure if you are waiting for a review from Woody in CC? Simon
On Sun, Jan 13, 2019 at 11:43 AM Simon Marchi <simon.marchi@polymtl.ca> wrote: > > On 2019-01-13 14:33, Max Filippov wrote: > > On Sun, Jan 13, 2019 at 8:32 AM Simon Marchi <simon.marchi@polymtl.ca> > > wrote: > >> > >> On 2019-01-13 03:36, Max Filippov wrote: > >> > In the original code (prior to 37d9e0623102) num_regs was the smallest > >> > of > >> > the number of the first pseudo register or the first privileged > >> > register, and > >> > num_pseudo_regs was the total number of registers minus num_regs. > >> > The register table is constructed so that pseudo registers are always > >> > at the > >> > end of it, so num_regs was always equal to num_nonpriv_regs. > >> > I'd like to restore this in xtensa-linux gdb, and what I do is I > >> > increase > >> > num_pseudo_regs by the difference of num_regs and num_nonpriv regs > >> > and set num_regs equal to num_nonpriv_regs to maintain the above > >> > equations. > >> > >> "num_regs == num_nonpriv_regs": is this only true for Linux, because > >> we > >> don't have access to privileged registers (and therefore there are 0 > >> nonpriv registers)? > > > > Correct. > > > >> For bare-metal, num_regs would be greater than num_nonpriv_regs? > > > > Correct. > > Ok. For the record, the patch LGTM, but I am not sure if you are waiting > for a review from Woody in CC? I'm cc'ing Woody as he's the maintainer of the xtensa gdb in Cadence/Tensilica. This patch is a resend of an old bugfix, I guess he'd reply if there was any concern first time I sent it.
On Sun, Jan 13, 2019 at 11:43 AM Simon Marchi <simon.marchi@polymtl.ca> wrote: > Ok. For the record, the patch LGTM, but I am not sure if you are waiting > for a review from Woody in CC? Thanks for the review. I've committed this change to master. -- Max
diff --git a/gdb/xtensa-linux-tdep.c b/gdb/xtensa-linux-tdep.c index 1764b953a00b..796143c6699b 100644 --- a/gdb/xtensa-linux-tdep.c +++ b/gdb/xtensa-linux-tdep.c @@ -101,7 +101,13 @@ xtensa_linux_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch) struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch); if (tdep->num_nopriv_regs < tdep->num_regs) - tdep->num_regs = tdep->num_nopriv_regs; + { + tdep->num_pseudo_regs += tdep->num_regs - tdep->num_nopriv_regs; + tdep->num_regs = tdep->num_nopriv_regs; + + set_gdbarch_num_regs (gdbarch, tdep->num_regs); + set_gdbarch_num_pseudo_regs (gdbarch, tdep->num_pseudo_regs); + } linux_init_abi (info, gdbarch);