From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32148 invoked by alias); 19 Feb 2015 18:30:47 -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 32139 invoked by uid 89); 19 Feb 2015 18:30:46 -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 18:30:45 +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 t1JIUbPQ008564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 19 Feb 2015 13:30:37 -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 t1JIUZ5L008659; Thu, 19 Feb 2015 13:30:36 -0500 Message-ID: <54E62BCB.80600@redhat.com> Date: Thu, 19 Feb 2015 18:30: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" 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> <87vbix3iqm.fsf@oracle.com> In-Reply-To: <87vbix3iqm.fsf@oracle.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-02/txt/msg00552.txt.bz2 On 02/19/2015 05:37 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? > > 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: Ah, right. > gdb_byte *buf; > [...] > dtrace_process_dof (sect, objfile, probesp, (struct dtrace_dof_hdr *) buf); Hmm, still, but I think this may be alright. gdb_bfd_map_section and bfd_get_full_section_contents return allocated objects, which have no declared type to begin with (C99 6.5/6, footnote 75). Then per C99 6.5/6, since the allocated object is never written through an lvalue with a type that is not a character type, then the effective type of the object is "simply the type of the lvalue used for the access." So it seems to me that casting to struct dtrace_dof_hdr * and then reading from that lvalue is OK: from that point on, the object pointed at by BUF has effective type struct dtrace_dof_hdr. Thanks, Pedro Alves