From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6377 invoked by alias); 19 Feb 2015 15:55:41 -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 6364 invoked by uid 89); 19 Feb 2015 15:55:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD,UNPARSEABLE_RELAY autolearn=ham version=3.3.2 X-HELO: aserp1040.oracle.com Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com) (141.146.126.69) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Thu, 19 Feb 2015 15:55:39 +0000 Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t1JFtSln023673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Feb 2015 15:55:28 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t1JFtS3r001314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Feb 2015 15:55:28 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t1JFtSUV015972; Thu, 19 Feb 2015 15:55:28 GMT Received: from termi.oracle.com (/10.175.252.152) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 19 Feb 2015 07:55:22 -0800 From: jose.marchesi@oracle.com (Jose E. Marchesi) To: Steve Ellcey Cc: Sergio Durigan Junior , Subject: Re: Build failure with probe patch References: <87wq3ercw0.fsf@redhat.com> <1424306916.27855.115.camel@ubuntu-sellcey> Date: Thu, 19 Feb 2015 15:55:00 -0000 In-Reply-To: <1424306916.27855.115.camel@ubuntu-sellcey> (Steve Ellcey's message of "Wed, 18 Feb 2015 16:48:36 -0800") Message-ID: <87r3tl7uwz.fsf@oracle.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2015-02/txt/msg00540.txt.bz2 Hi Steve. > According to: > > > > This warning has been removed from GCC. And by looking at the code > referenced by it, I don't see anything wrong there. So I'd say you can > ignore this (and probably update your GCC). > I would like to avoid updating GCC if possible. I build on old systems because some of our customers use old systems. I don't know if gdb has a 'minimal GCC' that it can be compiled with like GCC and some other projects have. I tried changing the definition of 'dof' to be ' bfd_byte *' instead of 'struct dtrace_dof_hdr *' and then casting it on the call to dtrace_process_dof instead of the call to bfd_malloc_and_get_section. I think that version would still break the strict aliasing rules, since `struct dtrace_dof_hdr' does not alias bfd_byte, even if the latter is a character type. As nothing guarantees that some future GCC version will not be bitching about it, what about using something like this instead? if (elf_section_data (sect)->this_hdr.sh_type == SHT_SUNW_dof) { /* Read the contents of the DOF section and then process it to extract the information of any probe defined into it. */ bfd_size_type size; const void *buf = gdb_bfd_map_section (sect, &size); dtrace_process_dof (sect, objfile, probesp, (struct dtrace_dof_hdr *) buf); } AFAIU anything can alias a void pointer, as void pointers can't be dereferenced...