From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 80211 invoked by alias); 11 Apr 2019 14:12:44 -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 80200 invoked by uid 89); 11 Apr 2019 14:12:43 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,KHOP_DYNAMIC,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1 spammy= X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0a-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.156.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 11 Apr 2019 14:12:42 +0000 Received: from pps.filterd (m0098393.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x3BE9T6P141866 for ; Thu, 11 Apr 2019 10:12:38 -0400 Received: from e16.ny.us.ibm.com (e16.ny.us.ibm.com [129.33.205.206]) by mx0a-001b2d01.pphosted.com with ESMTP id 2rt6ughagj-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 11 Apr 2019 10:12:37 -0400 Received: from localhost by e16.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 11 Apr 2019 15:12:14 +0100 Received: from b01cxnp23034.gho.pok.ibm.com (9.57.198.29) by e16.ny.us.ibm.com (146.89.104.203) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Thu, 11 Apr 2019 15:12:13 +0100 Received: from b01ledav004.gho.pok.ibm.com (b01ledav004.gho.pok.ibm.com [9.57.199.109]) by b01cxnp23034.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x3BECBP432047240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 11 Apr 2019 14:12:12 GMT Received: from b01ledav004.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6B8AF112069; Thu, 11 Apr 2019 14:12:11 +0000 (GMT) Received: from b01ledav004.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 29218112063; Thu, 11 Apr 2019 14:12:11 +0000 (GMT) Received: from pedro.localdomain (unknown [9.18.235.80]) by b01ledav004.gho.pok.ibm.com (Postfix) with ESMTP; Thu, 11 Apr 2019 14:12:11 +0000 (GMT) Received: by pedro.localdomain (Postfix, from userid 1000) id E48DD3C1101; Thu, 11 Apr 2019 11:12:02 -0300 (-03) From: Pedro Franco de Carvalho To: Alan Hayward , Ulrich Weigand Cc: Simon Marchi , "gdb-patches\\\@sourceware.org" , nd Subject: Re: [PATCH 2/2] gdbserver: Add linux_get_hwcap In-Reply-To: Date: Thu, 11 Apr 2019 14:12:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable x-cbid: 19041114-0072-0000-0000-000004189A22 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00010908; HX=3.00000242; KW=3.00000007; PH=3.00000004; SC=3.00000284; SDB=6.01187560; UDB=6.00622063; IPR=6.00968324; MB=3.00026393; MTD=3.00000008; XFM=3.00000015; UTC=2019-04-11 14:12:14 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19041114-0073-0000-0000-00004BC9DFA0 Message-Id: <87bm1cfx71.fsf@linux.vnet.ibm.com> X-IsSubscribed: yes X-SW-Source: 2019-04/txt/msg00200.txt.bz2 Hi Alan, Thank you for the comments. Alan Hayward writes: >> -static CORE_ADDR >> -linux_get_auxv (int wordsize, CORE_ADDR match) >> +int >> +linux_get_auxv (int wordsize, CORE_ADDR match, CORE_ADDR *valp) >> { >> gdb_byte *data =3D (gdb_byte *) alloca (2 * wordsize); >> int offset =3D 0; > > Would be useful to set valp to zero here. (Not sure if the GDB version > does this either). The client version doesn't do this (target_auxv_search). Should I be consistent with that or change it here? > I don=E2=80=99t think there is a requirement here for the error to be ret= urn separately > to the phdr. With the my version of linux_get_auxv, on error you would ge= t 0 > for phdr. Given that it is an address, 0 should never be a valid value. > > With the code pre my patch and this patch, I=E2=80=99m not sure what will= happen if the > PHDR value is 0 - will read_inferior_memory then the memcmp deal with tha= t? (To > be fair, I suspect there are bigger issues to deal with if phdr is 0). I'm probably nitpicking, but I tried using memory at 0x0 with mmap and it seems to work, even if it is unusual, and gdb can read from that address, so apparently ptrace can read memory at 0x0, which should mean that read_inferior_memory can do that too. Still, I don't think the program headers could really be at 0x0, since there would be no room for the ELF header before that. However, wouldn't it make sense to return in error separately, so that the next person who reads that function doesn't have to go through this reasoning? Besides, other auxv values that might be retrieved in the future with linux_get_auxv could have a real meaning for 0. Other than that, I agree with your other comments. > Thanks, > Alan. Thanks! -- Pedro Franco de Carvalho