From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 63180 invoked by alias); 26 Mar 2015 23:39: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 63169 invoked by uid 89); 26 Mar 2015 23:39:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00,LIKELY_SPAM_BODY,SPF_PASS,T_RP_MATCHES_RCVD,UNPARSEABLE_RELAY autolearn=no 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, 26 Mar 2015 23:39:45 +0000 Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t2QNdcZi011408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Mar 2015 23:39:39 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t2QNdc6X013836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 26 Mar 2015 23:39:38 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t2QNdbSC004219; Thu, 26 Mar 2015 23:39:37 GMT Received: from termi.oracle.com (/85.53.245.107) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 26 Mar 2015 16:39:37 -0700 From: jose.marchesi@oracle.com (Jose E. Marchesi) To: Joel Brobecker Cc: Sergio Durigan Junior , gdb-patches@sourceware.org Subject: Re: [PATCH V4 5/9] New probe type: DTrace USDT probes. References: <1422874968-382-1-git-send-email-jose.marchesi@oracle.com> <1422874968-382-6-git-send-email-jose.marchesi@oracle.com> <87r3tp722i.fsf@redhat.com> <20150325191418.GA32233@adacore.com> <87bnjfraq1.fsf@oracle.com> <20150326175028.GA13867@adacore.com> Date: Thu, 26 Mar 2015 23:39:00 -0000 In-Reply-To: <20150326175028.GA13867@adacore.com> (Joel Brobecker's message of "Thu, 26 Mar 2015 10:50:28 -0700") Message-ID: <87lhijwcfd.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-03/txt/msg00878.txt.bz2 > Could you please send me your sparc-solaris reproducer? Thanks for the offer to help! Sadly, the SEGV doesn't seem to happen on sparc-solaris, it seems. Once I apply the patch above, I pretty much get normal results back (yay!). So, the problem appears to be specific to x86-solaris. I didn't know the DOF program was embedded in the executable, but I suspect there is a problem in its contents. How do you think we should proceed? Hmm, this may be an endianness problem: /* DOF supports two different encodings: MSB (big-endian) and LSB (little-endian). The encoding is itself encoded in the DOF header. The following function returns an unsigned value in the host endianness. */ #define DOF_UINT(dof, field) \ extract_unsigned_integer ((gdb_byte *) &(field), \ sizeof ((field)), \ (((dof)->dofh_ident[DTRACE_DOF_ID_ENCODING] \ == DTRACE_DOF_ENCODE_MSB) \ ? BFD_ENDIAN_BIG : BFD_ENDIAN_LITTLE)) We know for a fact that the implementation works properly on a little-endian host (x86) and little-endian DOF data (generated by either pdtrace or dtrace). I would need to look at the x86-solaris binaries you are using. Maybe dtrace on that platform is generating big-endian DOF data in the little-endian platform and the implementation is not handling that properly.