Message ID | 20170610133422.19913-1-shorne@gmail.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 52038 invoked by alias); 10 Jun 2017 13:34:26 -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 52029 invoked by uid 89); 10 Jun 2017 13:34:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-25.7 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 spammy=cpn X-HELO: mail-pf0-f181.google.com Received: from mail-pf0-f181.google.com (HELO mail-pf0-f181.google.com) (209.85.192.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 10 Jun 2017 13:34:23 +0000 Received: by mail-pf0-f181.google.com with SMTP id 83so37171703pfr.0 for <gdb-patches@sourceware.org>; Sat, 10 Jun 2017 06:34:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=48bu0+sJgxKyn5LvRBp4AAxyaS8wcAsBMG8svPAN6oA=; b=Q28h/zavwPCYpjFP09qRh6aIf0jcDzNP3qpvcqTTaWbS3twj3bCLYM0x0jRcaMFuQi fGWp+Lc/Xm9qhoo+XNnM+/EHJORiZvQFfyB/9SusDK1lW5lLwY00lZ1iL6um0GghuxsN W0KFyhgIo6Ws2Owue6FyPsJ+CFU+vplAxs/FFvkdPw738I/Z3Kljstf7MnLmwIM+ISJW 4m3liGSmp2MgppoNoC1Tu3x1K+kCCTYV7fjDU1zO6fgS0tQ+j8V6IH44B1QLC314Dwi7 qlPNShWwgJrRBB55+zxt0VWq+iydBvzRoPmJGqDiMhnTPY+q4nHudNcJ/zdDBDH9AG9a Pr/Q== X-Gm-Message-State: AODbwcBUAZnqzDniDGxESdmCuuy7vj5i0LsGehSZjwQmyooP/FJV0Duz LK46DM0qAPmhiJKdJxeD2w== X-Received: by 10.84.217.148 with SMTP id p20mr46806581pli.196.1497101666710; Sat, 10 Jun 2017 06:34:26 -0700 (PDT) Received: from localhost (g212.61-193-241.ppp.wakwak.ne.jp. [61.193.241.212]) by smtp.gmail.com with ESMTPSA id g70sm8222840pfc.47.2017.06.10.06.34.25 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 10 Jun 2017 06:34:26 -0700 (PDT) From: Stafford Horne <shorne@gmail.com> To: GDB patches <gdb-patches@sourceware.org> Cc: Stafford Horne <shorne@gmail.com> Subject: [PATCH] xtensa: Properly strdup string when building reggroup Date: Sat, 10 Jun 2017 22:34:22 +0900 Message-Id: <20170610133422.19913-1-shorne@gmail.com> X-IsSubscribed: yes |
Commit Message
Stafford Horne
June 10, 2017, 1:34 p.m. UTC
I noticed this while looking at the reggroup intializations. It seems for xtensa the "cpN" reggroup->name is getting assigned to the same text pointer for each iteration of XTENSA_MAX_COPROCESSOR. Note 1, internally reggroup_new() does not do any xstrdup(). Note 2, I could not test this. gdb/ChangeLog: 2017-06-10 Stafford Horne <shorne@gmail.com> * xtensa-tdep.c (xtensa_init_reggroups): Use xstrdup for cpname. --- gdb/xtensa-tdep.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Comments
Stafford Horne <shorne@gmail.com> writes: Patch is good to me, a nit, > - xtensa_cp[i] = reggroup_new (cpname, USER_REGGROUP); > + xtensa_cp[i] = reggroup_new (xstrdup(cpname), USER_REGGROUP); "xstrdup (cpname)". Before your patch is applied, GDB prints some garbage data, (gdb) set architecture xtensa The target architecture is assumed to be xtensa (gdb) maintenance print reggroups Group Type all user save internal restore internal system user vector user general user float user ar user user user vectra user P�^\U user P�^\U user P�^\U user P�^\U user P�^\U user P�^\U user P�^\U user P�^\U user P�^\U user P�^\U user P�^\U user P�^\U user P�^\U user P�^\U user P�^\U user P�^\U user with your patch applied, the output looks "right", (gdb) maintenance print reggroups Group Type all user save internal restore internal system user vector user general user float user ar user user user vectra user cp0 user cp1 user cp2 user cp3 user cp4 user cp5 user cp6 user cp7 user cp8 user cp9 user cp: user cp; user cp< user cp= user cp> user cp? user This exposes another bug, IMO, here, for (i = 0; i < XTENSA_MAX_COPROCESSOR; i++) { cpname[2] = '0' + i; xtensa_cp[i] = reggroup_new (cpname, USER_REGGROUP); } and XTENSA_MAX_COPROCESSOR is 0x10, so we can see "cp:", "cp;", which looks odd.
On 2017-06-12 10:22, Yao Qi wrote: > This exposes another bug, IMO, here, > > for (i = 0; i < XTENSA_MAX_COPROCESSOR; i++) > { > cpname[2] = '0' + i; > xtensa_cp[i] = reggroup_new (cpname, USER_REGGROUP); > } > > and XTENSA_MAX_COPROCESSOR is 0x10, so we can see "cp:", "cp;", which > looks odd. Heh, looks like the patch here https://sourceware.org/ml/gdb-patches/2011-03/msg00571.html did not take that into account :)
On Mon, Jun 12, 2017 at 10:38:09AM +0200, Simon Marchi wrote: > On 2017-06-12 10:22, Yao Qi wrote: > > This exposes another bug, IMO, here, > > > > for (i = 0; i < XTENSA_MAX_COPROCESSOR; i++) > > { > > cpname[2] = '0' + i; > > xtensa_cp[i] = reggroup_new (cpname, USER_REGGROUP); > > } > > > > and XTENSA_MAX_COPROCESSOR is 0x10, so we can see "cp:", "cp;", which > > looks odd. > > Heh, looks like the patch here > > https://sourceware.org/ml/gdb-patches/2011-03/msg00571.html > > did not take that into account :) Right, I might was well resend the patch with an sprintf(). -Stafford
diff --git a/gdb/xtensa-tdep.c b/gdb/xtensa-tdep.c index f9e8584..cfbddf2 100644 --- a/gdb/xtensa-tdep.c +++ b/gdb/xtensa-tdep.c @@ -746,7 +746,7 @@ xtensa_init_reggroups (void) for (i = 0; i < XTENSA_MAX_COPROCESSOR; i++) { cpname[2] = '0' + i; - xtensa_cp[i] = reggroup_new (cpname, USER_REGGROUP); + xtensa_cp[i] = reggroup_new (xstrdup(cpname), USER_REGGROUP); } }