From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13645 invoked by alias); 19 Feb 2015 17:32:16 -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 13635 invoked by uid 89); 19 Feb 2015 17:32:16 -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 17:32:15 +0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t1JHW0XR007535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Feb 2015 17:32:01 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id t1JHVxdb016947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 19 Feb 2015 17:32:00 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t1JHVxc3015533; Thu, 19 Feb 2015 17:31:59 GMT Received: from termi.oracle.com (/10.175.252.152) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 19 Feb 2015 09:31:58 -0800 From: jose.marchesi@oracle.com (Jose E. Marchesi) To: Pedro Alves Cc: Steve Ellcey , Sergio Durigan Junior , gdb-patches@sourceware.org Subject: Re: Build failure with probe patch References: <87wq3ercw0.fsf@redhat.com> <1424306916.27855.115.camel@ubuntu-sellcey> <87r3tl7uwz.fsf@oracle.com> <54E6150B.9060808@redhat.com> Date: Thu, 19 Feb 2015 17:32:00 -0000 In-Reply-To: <54E6150B.9060808@redhat.com> (Pedro Alves's message of "Thu, 19 Feb 2015 16:53:31 +0000") Message-ID: <87vbix3iqm.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/msg00549.txt.bz2 > > 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. Hmm, I thought that for aliasing, a typedef to char could alias anything, as typedefs don't really create new types? Yes, but not the other way around... it is not allowed to alias a character type with a non-character type like in the following call to dtrace_process_dof: gdb_byte *buf; [...] dtrace_process_dof (sect, objfile, probesp, (struct dtrace_dof_hdr *) buf); > 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... > gdb_bfd_map_section may be better for making use of mmap if possible, but note that even though that might shut up some versions of some compilers, WRT to strict aliasing, that ends up being no different from Steve's suggestion, plus with an intermediate void* cast. gdb_bfd_map_section also returns a gdb_byte *. (And with C++, that'll end up needing an explicit '(void *)' cast.). I see, void is not allowed to alias a char... we are doomed! :D Oh well, I guess we will have to use an union to avoid any possible strict-aliasing warning... Can we assume C99 in GDB?