From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 98655 invoked by alias); 23 Nov 2015 13:24:22 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 98642 invoked by uid 89); 23 Nov 2015 13:24:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_20,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 23 Nov 2015 13:24:20 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 91C33C0F1D01; Mon, 23 Nov 2015 13:24:18 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-34.ams2.redhat.com [10.36.116.34]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tANDOHFb008898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 23 Nov 2015 08:24:18 -0500 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id tANDOEM9026355; Mon, 23 Nov 2015 14:24:15 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id tANDOBPY026354; Mon, 23 Nov 2015 14:24:11 +0100 Date: Mon, 23 Nov 2015 13:29:00 -0000 From: Jakub Jelinek To: Maxim Ostapenko Cc: Christophe Lyon , Kostya Serebryany , GCC Patches , Yury Gribov , Vyacheslav Barinov , Slava Garbuzov , Adhemerval Zanella Subject: Re: [PATCH 1/2] Libsanitizer merge from upstream r253555. Message-ID: <20151123132411.GB5675@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <5652C3E0.4030000@partner.samsung.com> <5652C459.8090500@partner.samsung.com> <20151123080753.GS5675@tucnak.redhat.com> <565307B5.3000901@partner.samsung.com> <20151123124112.GA5675@tucnak.redhat.com> <565312DE.2020207@partner.samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <565312DE.2020207@partner.samsung.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg02709.txt.bz2 On Mon, Nov 23, 2015 at 04:21:34PM +0300, Maxim Ostapenko wrote: > Yeah, right. I've asked about kernel headers just to make sure I correctly > understand the issue. > > Actually, I see such code in > lib/sanitizer_common/sanitizer_platform_limits_posix.cc: > > #if defined(PTRACE_GETVFPREGS) && defined(PTRACE_SETVFPREGS) > int ptrace_getvfpregs = PTRACE_GETVFPREGS; > int ptrace_setvfpregs = PTRACE_SETVFPREGS; > #else > int ptrace_getvfpregs = -1; > int ptrace_setvfpregs = -1; > #endif > > and in ptrace interceptor: > > else if (request == ptrace_setvfpregs) > COMMON_INTERCEPTOR_READ_RANGE(ctx, data, struct_user_vfpregs_struct_sz); > else if (request == ptrace_getvfpregs) > COMMON_INTERCEPTOR_WRITE_RANGE(ctx, data, struct_user_vfpregs_struct_sz) > > So, perhaps we can do the same thing with ARM_VFPREGS_SIZE, something like > this? > > diff --git > a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc > b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc > index 9866cc9..20ff224 100644 > --- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc > +++ b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc > @@ -323,10 +323,14 @@ unsigned struct_ElfW_Phdr_sz = sizeof(Elf_Phdr); > unsigned struct_user_fpxregs_struct_sz = sizeof(struct > user_fpxregs_struct); > #endif // __x86_64 || __mips64 || __powerpc64__ || __aarch64__ || __arm__ > #ifdef __arm__ > +#if defined(ARM_VFPREGS_SIZE) > unsigned struct_user_vfpregs_struct_sz = ARM_VFPREGS_SIZE; > #else > unsigned struct_user_vfpregs_struct_sz = 0; > #endif > +#else > + unsigned struct_user_vfpregs_struct_sz = 0; > +#endif Maybe, but then it would need to be approved upstream. If you just define ARM_VFPREGS_SIZE to 0 or whatever else in the GCC owned wrapper headers, you can avoid that. I guess talk to upstream. Jakub