From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22633 invoked by alias); 19 Feb 2015 16:53:46 -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 22617 invoked by uid 89); 19 Feb 2015 16:53:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD 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; Thu, 19 Feb 2015 16:53:44 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1JGrY99014908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 19 Feb 2015 11:53:34 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1JGrVeh032232; Thu, 19 Feb 2015 11:53:32 -0500 Message-ID: <54E6150B.9060808@redhat.com> Date: Thu, 19 Feb 2015 16:53:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Jose E. Marchesi" , Steve Ellcey CC: 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> In-Reply-To: <87r3tl7uwz.fsf@oracle.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-02/txt/msg00547.txt.bz2 On 02/19/2015 04:01 PM, Jose E. Marchesi wrote: > > > 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? > 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.). Thanks, Pedro Alves