From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30142 invoked by alias); 19 Feb 2015 20:11:51 -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 30133 invoked by uid 89); 19 Feb 2015 20:11:50 -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 20:11:49 +0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t1JKBgYD025061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Feb 2015 20:11:42 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t1JKBfVI017810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Feb 2015 20:11:41 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t1JKBfbr003262; Thu, 19 Feb 2015 20:11:41 GMT Received: from termi.oracle.com (/10.175.252.152) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 19 Feb 2015 12:11:35 -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> <87vbix3iqm.fsf@oracle.com> <54E62BCB.80600@redhat.com> Date: Thu, 19 Feb 2015 20:11:00 -0000 In-Reply-To: <54E62BCB.80600@redhat.com> (Pedro Alves's message of "Thu, 19 Feb 2015 18:30:35 +0000") Message-ID: <87lhjtzmf2.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/msg00553.txt.bz2 > 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. Good point! Yes, I agree. Both bfd_byte and gdb_byte are character types, so the object returned by either bfd_malloc_and_get_section or gdb_bfd_map_section must retain the property of not having a declared type.