Message ID | 20230208195226.144143-5-iii@linux.ibm.com |
---|---|
State | Superseded |
Headers |
Return-Path: <elfutils-devel-bounces+patchwork=sourceware.org@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id EFCD43850401 for <patchwork@sourceware.org>; Wed, 8 Feb 2023 19:53:34 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EFCD43850401 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1675886015; bh=Ri02A5Mf+HnwfkNDfbJq9wlenoTh+FjkFeNFRat5C6o=; h=To:Cc:Subject:Date:In-Reply-To:References:List-Id: List-Unsubscribe:List-Archive:List-Help:List-Subscribe:From: Reply-To:From; b=tkyyDIzcp6mlnOvXM+Aoh1njD1uhn+4weBcaPHwk5j31QZpCg7x8H2SnWScDMo20B HgpeYxu0Z9y3aUB0tcUy8XWnigMNZ20co6wfW22tQh6KlYdrMsv2so3GON0AVntYOe 1HMauQF8mLUz5ZI40CtHIAGe7eCRyeZD4MZZ8zKw= X-Original-To: elfutils-devel@sourceware.org Delivered-To: elfutils-devel@sourceware.org Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 00CC73858C39 for <elfutils-devel@sourceware.org>; Wed, 8 Feb 2023 19:52:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 00CC73858C39 Received: from pps.filterd (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 318J8uQc005413; Wed, 8 Feb 2023 19:52:39 GMT Received: from ppma04ams.nl.ibm.com (63.31.33a9.ip4.static.sl-reverse.com [169.51.49.99]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3nmhdch8uc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 08 Feb 2023 19:52:39 +0000 Received: from pps.filterd (ppma04ams.nl.ibm.com [127.0.0.1]) by ppma04ams.nl.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 3185agCr024247; Wed, 8 Feb 2023 19:52:36 GMT Received: from smtprelay01.fra02v.mail.ibm.com ([9.218.2.227]) by ppma04ams.nl.ibm.com (PPS) with ESMTPS id 3nhf06wakx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 08 Feb 2023 19:52:36 +0000 Received: from smtpav06.fra02v.mail.ibm.com (smtpav06.fra02v.mail.ibm.com [10.20.54.105]) by smtprelay01.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 318JqXNI47186376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 8 Feb 2023 19:52:33 GMT Received: from smtpav06.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 069FA20043; Wed, 8 Feb 2023 19:52:33 +0000 (GMT) Received: from smtpav06.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id AACD620040; Wed, 8 Feb 2023 19:52:32 +0000 (GMT) Received: from heavy.ibmuc.com (unknown [9.179.24.149]) by smtpav06.fra02v.mail.ibm.com (Postfix) with ESMTP; Wed, 8 Feb 2023 19:52:32 +0000 (GMT) To: Mark Wielaard <mark@klomp.org> Cc: elfutils-devel@sourceware.org, Ilya Leoshkevich <iii@linux.ibm.com> Subject: [PATCH v2 4/7] x86_64_return_value_location: Support lvalue and rvalue references Date: Wed, 8 Feb 2023 20:52:23 +0100 Message-Id: <20230208195226.144143-5-iii@linux.ibm.com> X-Mailer: git-send-email 2.39.1 In-Reply-To: <20230208195226.144143-1-iii@linux.ibm.com> References: <20230208195226.144143-1-iii@linux.ibm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: nhDCDI_eVDzioS1YApcEIXgul9-KVz2M X-Proofpoint-GUID: nhDCDI_eVDzioS1YApcEIXgul9-KVz2M X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.930,Hydra:6.0.562,FMLib:17.11.122.1 definitions=2023-02-08_09,2023-02-08_02,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 suspectscore=0 phishscore=0 impostorscore=0 clxscore=1015 malwarescore=0 mlxscore=0 mlxlogscore=978 spamscore=0 adultscore=0 priorityscore=1501 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2302080167 X-Spam-Status: No, score=-11.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, GIT_PATCH_0, SPF_HELO_NONE, SPF_PASS, 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 X-BeenThere: elfutils-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Elfutils-devel mailing list <elfutils-devel.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/elfutils-devel>, <mailto:elfutils-devel-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/elfutils-devel/> List-Help: <mailto:elfutils-devel-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/elfutils-devel>, <mailto:elfutils-devel-request@sourceware.org?subject=subscribe> From: Ilya Leoshkevich via Elfutils-devel <elfutils-devel@sourceware.org> Reply-To: Ilya Leoshkevich <iii@linux.ibm.com> Errors-To: elfutils-devel-bounces+patchwork=sourceware.org@sourceware.org Sender: "Elfutils-devel" <elfutils-devel-bounces+patchwork=sourceware.org@sourceware.org> |
Series |
Add Memory Sanitizer support
|
|
Commit Message
Ilya Leoshkevich
Feb. 8, 2023, 7:52 p.m. UTC
On the low level, they are the same as pointers.
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
---
backends/x86_64_retval.c | 2 ++
1 file changed, 2 insertions(+)
Comments
Hi Ilya, On Wed, 2023-02-08 at 20:52 +0100, Ilya Leoshkevich wrote: > On the low level, they are the same as pointers. Yes, I can see how that would work for return types. Do you happen to have a testcase for this? Right below this code is a check whether the type has a DW_AT_byte_size, and if not we'll assume 8 as (address) size if the type is either DW_TAG_pointer_type or DW_TAG_ptr_to_member_type. Should the same be done for DW_TAG_reference_type and DW_TAG_rvalue_reference_type? This doesn't seem x86_64 specific, other backends have similar code, I assume they all need a similar update? Thanks, Mark > Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> > --- > backends/x86_64_retval.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/backends/x86_64_retval.c b/backends/x86_64_retval.c > index f9114cb1..e668eacc 100644 > --- a/backends/x86_64_retval.c > +++ b/backends/x86_64_retval.c > @@ -106,6 +106,8 @@ x86_64_return_value_location (Dwarf_Die *functypedie, const Dwarf_Op **locp) > case DW_TAG_enumeration_type: > case DW_TAG_pointer_type: > case DW_TAG_ptr_to_member_type: > + case DW_TAG_reference_type: > + case DW_TAG_rvalue_reference_type: > { > Dwarf_Attribute attr_mem; > if (dwarf_formudata (dwarf_attr_integrate (typedie, DW_AT_byte_size,
On Thu, 2023-02-09 at 14:45 +0100, Mark Wielaard wrote: > Hi Ilya, > > On Wed, 2023-02-08 at 20:52 +0100, Ilya Leoshkevich wrote: > > On the low level, they are the same as pointers. > > Yes, I can see how that would work for return types. > Do you happen to have a testcase for this? You can trigger the issue by compiling the following: $ cat 1.cpp int &foo() { throw; } int &&bar() { throw; } $ g++ -g 1.cpp -c and then running $ LD_LIBRARY_PATH=../libelf:../libdw ./funcretval -e 1.o What would be a good way to integrate such a testcase? Currently all tests are built with gcc, is it okay to add one built with g++? If not, I guess the alternative would be to check in multiple compressed object files built for different platforms? > Right below this code is a check whether the type has a > DW_AT_byte_size, and if not we'll assume 8 as (address) size if the > type is either DW_TAG_pointer_type or DW_TAG_ptr_to_member_type. > Should the same be done for DW_TAG_reference_type and > DW_TAG_rvalue_reference_type? Sounds reasonable. Here is what I have on x86_64: <1><5a>: Abbrev Number: 1 (DW_TAG_reference_type) <5b> DW_AT_byte_size : 8 <1><80>: Abbrev Number: 7 (DW_TAG_rvalue_reference_type) <81> DW_AT_byte_size : 8 IIUC these checks handle weird compilers that do not emit DW_AT_byte_size. > This doesn't seem x86_64 specific, other backends have similar code, > I > assume they all need a similar update? Oh, right, this issue seems to affect all of them. > Thanks, > > Mark > > > Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> > > --- > > backends/x86_64_retval.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/backends/x86_64_retval.c b/backends/x86_64_retval.c > > index f9114cb1..e668eacc 100644 > > --- a/backends/x86_64_retval.c > > +++ b/backends/x86_64_retval.c > > @@ -106,6 +106,8 @@ x86_64_return_value_location (Dwarf_Die > > *functypedie, const Dwarf_Op **locp) > > case DW_TAG_enumeration_type: > > case DW_TAG_pointer_type: > > case DW_TAG_ptr_to_member_type: > > + case DW_TAG_reference_type: > > + case DW_TAG_rvalue_reference_type: > > { > > Dwarf_Attribute attr_mem; > > if (dwarf_formudata (dwarf_attr_integrate (typedie, > > DW_AT_byte_size, >
Hi - > $ cat 1.cpp > int &foo() { throw; } > int &&bar() { throw; } > $ g++ -g 1.cpp -c > and then running > > $ LD_LIBRARY_PATH=../libelf:../libdw ./funcretval -e 1.o > > What would be a good way to integrate such a testcase? > Currently all tests are built with gcc, is it okay to add one > built with g++? [...] Sure. - FChE
diff --git a/backends/x86_64_retval.c b/backends/x86_64_retval.c index f9114cb1..e668eacc 100644 --- a/backends/x86_64_retval.c +++ b/backends/x86_64_retval.c @@ -106,6 +106,8 @@ x86_64_return_value_location (Dwarf_Die *functypedie, const Dwarf_Op **locp) case DW_TAG_enumeration_type: case DW_TAG_pointer_type: case DW_TAG_ptr_to_member_type: + case DW_TAG_reference_type: + case DW_TAG_rvalue_reference_type: { Dwarf_Attribute attr_mem; if (dwarf_formudata (dwarf_attr_integrate (typedie, DW_AT_byte_size,