From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 39094 invoked by alias); 12 Jun 2017 08:22:09 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 38538 invoked by uid 89); 12 Jun 2017 08:22:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=P, (unknown), vectra, p X-HELO: mail-it0-f41.google.com Received: from mail-it0-f41.google.com (HELO mail-it0-f41.google.com) (209.85.214.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 12 Jun 2017 08:22:05 +0000 Received: by mail-it0-f41.google.com with SMTP id m47so17500420iti.0 for ; Mon, 12 Jun 2017 01:22:10 -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:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=hpv0od4BdClKZ0yq4Z3RtzMR0RpsItgC5F3N+byAkTg=; b=qbfEl9Wn8a4wp/p06MmSEqyBwTiBZLwapc6Crymby1HQ8jEAL+nKtwjyT7QyF0PKFh mKKWzrT3w4wqMbOTtVTdNRD+me+IVUrrP5q8NxLzmsvDz0uZ3f1F5Iyr3N3RS4ih71og eSYXBLMMfv0NKCrrpvtwOGz4rqz34vKTbk29U4hxjfVlJBWW+DPuLiE6+OaNwsk3TTNc yODCFir3/jJ5m+NLYtfj9bxlhT41dsAq9S6nZXmp8GVz2Zd33npamK+mWdT0POXo2irO aZsfX0ai+W2+a1x5Nj9Omt3yle5GzpkbJPOjPhMyHWX24qIer62nCr7mR4EwJirhqfVT INyw== X-Gm-Message-State: AODbwcBqzEMa/Fun+h65U93JPubdsV5/ANf7nRnF40Mqy6K7EdNFDTvH OsWvxAJNzi3tzP9N X-Received: by 10.36.101.147 with SMTP id u141mr10497522itb.8.1497255728477; Mon, 12 Jun 2017 01:22:08 -0700 (PDT) Received: from E107787-LIN (static.42.136.251.148.clients.your-server.de. [148.251.136.42]) by smtp.gmail.com with ESMTPSA id v13sm3766772ita.28.2017.06.12.01.22.07 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Mon, 12 Jun 2017 01:22:08 -0700 (PDT) From: Yao Qi To: Stafford Horne Cc: GDB patches Subject: Re: [PATCH] xtensa: Properly strdup string when building reggroup References: <20170610133422.19913-1-shorne@gmail.com> Date: Mon, 12 Jun 2017 08:22:00 -0000 In-Reply-To: <20170610133422.19913-1-shorne@gmail.com> (Stafford Horne's message of "Sat, 10 Jun 2017 22:34:22 +0900") Message-ID: <86poe9aa4y.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-06/txt/msg00269.txt.bz2 Stafford Horne writes: Patch is good to me, a nit, > - xtensa_cp[i] =3D reggroup_new (cpname, USER_REGGROUP); > + xtensa_cp[i] =3D 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=20 Group Type=20=20=20=20=20=20 all user=20=20=20=20=20=20 save internal=20=20 restore internal=20=20 system user=20=20=20=20=20=20 vector user=20=20=20=20=20=20 general user=20=20=20=20=20=20 float user=20=20=20=20=20=20 ar user=20=20=20=20=20=20 user user=20=20=20=20=20=20 vectra user=20=20=20=20=20=20 P=EF=BF=BD^\U user=20=20=20=20=20=20 P=EF=BF=BD^\U user=20=20=20=20=20=20 P=EF=BF=BD^\U user=20=20=20=20=20=20 P=EF=BF=BD^\U user=20=20=20=20=20=20 P=EF=BF=BD^\U user=20=20=20=20=20=20 P=EF=BF=BD^\U user=20=20=20=20=20=20 P=EF=BF=BD^\U user=20=20=20=20=20=20 P=EF=BF=BD^\U user P=EF=BF=BD^\U user=20=20=20=20=20=20 P=EF=BF=BD^\U user=20=20=20=20=20=20 P=EF=BF=BD^\U user=20=20=20=20=20=20 P=EF=BF=BD^\U user=20=20=20=20=20=20 P=EF=BF=BD^\U user=20=20=20=20=20=20 P=EF=BF=BD^\U user=20=20=20=20=20=20 P=EF=BF=BD^\U user P=EF=BF=BD^\U user with your patch applied, the output looks "right", (gdb) maintenance print reggroups Group Type=20=20=20=20=20=20 all user=20=20=20=20=20=20 save internal=20=20 restore internal=20=20 system user=20=20=20=20=20=20 vector user=20=20=20=20=20=20 general user=20=20=20=20=20=20 float user=20=20=20=20=20=20 ar user=20=20=20=20=20=20 user user=20=20=20=20=20=20 vectra user=20=20=20=20=20=20 cp0 user=20=20=20=20=20=20 cp1 user=20=20=20=20=20=20 cp2 user=20=20=20=20=20=20 cp3 user=20=20=20=20=20=20 cp4 user=20=20=20=20=20=20 cp5 user=20=20=20=20=20=20 cp6 user=20=20=20=20=20=20 cp7 user=20=20=20=20=20=20 cp8 user=20=20=20=20=20=20 cp9 user=20=20=20=20=20=20 cp: user=20=20=20=20=20=20 cp; user=20=20=20=20=20=20 cp< user=20=20=20=20=20=20 cp=3D user=20=20=20=20=20=20 cp> user=20=20=20=20=20=20 cp? user This exposes another bug, IMO, here, for (i =3D 0; i < XTENSA_MAX_COPROCESSOR; i++) { cpname[2] =3D '0' + i; xtensa_cp[i] =3D reggroup_new (cpname, USER_REGGROUP); } and XTENSA_MAX_COPROCESSOR is 0x10, so we can see "cp:", "cp;", which looks odd. --=20 Yao (=E9=BD=90=E5=B0=A7)