From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-121400-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 25427 invoked by alias); 31 Mar 2015 17:29:51 -0000
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
Received: (qmail 25351 invoked by uid 89); 31 Mar 2015 17:29:50 -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; Tue, 31 Mar 2015 17:29:49 +0000
Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234])	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t2VHTiwn009585	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);	Tue, 31 Mar 2015 17:29:44 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72])	by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t2VHTh7b012968	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);	Tue, 31 Mar 2015 17:29:43 GMT
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12])	by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t2VHTh5O021743;	Tue, 31 Mar 2015 17:29:43 GMT
Received: from termi.oracle.com (/10.175.202.119)	by default (Oracle Beehive Gateway v4.0)	with ESMTP ; Tue, 31 Mar 2015 10:29:42 -0700
From: jose.marchesi@oracle.com (Jose E. Marchesi)
To: Joel Brobecker <brobecker@adacore.com>
Cc: Sergio Durigan Junior <sergiodj@redhat.com>, 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: Tue, 31 Mar 2015 17:29:00 -0000
In-Reply-To: <20150326175028.GA13867@adacore.com> (Joel Brobecker's message of	"Thu, 26 Mar 2015 10:50:28 -0700")
Message-ID: <87y4mdjcie.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/msg01064.txt.bz2


Hi Joel.

    >     And once I had that fixed, the next issue that I looked at was:
    >     
    >         (gdb) b adainit
    >         Breakpoint 1 at 0x8051f03
    >         (gdb) run
    >         Starting program: /[...]/a
    >         [Thread debugging using libthread_db enabled]
    >         zsh: 12378 segmentation fault (core dumped)  /[...]/gdb -q a
    >     
    >     This is where I'm getting even more out of my league, here.
    >     The SEGV happens on the following line:
    >     
    >     377           uint32_t enabler_offset
    >     378             = ((uint32_t *) eofftab)[DOF_UINT (dof, probe->dofpr_enoffidx) + i];
    > 
    > I will debug that SIGSEGV in solaris, but the problem seems to be
    > related to the DOF program embedded in your program, more than to the
    > platform.
    > 
    > 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.

I just tried the following in a x86-solaris machine, using todays git
GDB:

$ uname -a
SunOS solaris-x86 5.11 11.1 i86pc i386 i86pc
$ cat > foo.d <<EOF
provider test {
 probe progress__counter (char *, int);
};
EOF
$ cat > foo.c <<EOF
#include "foo.h"

int
main ()
{
  char *name = "application";
  int i = 0;

  while (i < 10)
  {
    i++;
    if (TEST_PROGRESS_COUNTER_ENABLED())
      TEST_PROGRESS_COUNTER (name, i);
  }

  return 0;
}
EOF
$ dtrace -h -s foo.d -o foo.h
$ gcc -c foo.c
$ dtrace -G -s foo.d -o foo-p.o foo.o
$ gcc -o foo foo.o foo-p.o
$ gdb foo
[...]
(gdb) info probes
Type   Provider Name             Where      Enabled Object
dtrace test     progress-counter 0x08051024 unknown /export/home/jose/binutils-gdb/build/foo
(gdb) disas main
Dump of assembler code for function main:
0x08050fec <+0>:     push   %ebp
0x08050fed <+1>:     mov    %esp,%ebp
0x08050fef <+3>:     and    $0xfffffff0,%esp
0x08050ff2 <+6>:     sub    $0x20,%esp
0x08050ff5 <+9>:     movl   $0x80514f0,0x18(%esp)
0x08050ffd <+17>:    movl   $0x0,0x1c(%esp)
0x08051005 <+25>:    jmp    0x8051029 <main+61>
0x08051007 <+27>:    addl   $0x1,0x1c(%esp)
0x0805100c <+32>:    xor    %eax,%eax
0x0805100e <+34>:    nop
0x0805100f <+35>:    nop
0x08051010 <+36>:    nop
0x08051011 <+37>:    test   %eax,%eax
0x08051013 <+39>:    je     0x8051029 <main+61>
0x08051015 <+41>:    mov    0x1c(%esp),%eax
0x08051019 <+45>:    mov    %eax,0x4(%esp)
0x0805101d <+49>:    mov    0x18(%esp),%eax
0x08051021 <+53>:    mov    %eax,(%esp)
0x08051024 <+56>:    nop
0x08051025 <+57>:    nop
0x08051026 <+58>:    nop
0x08051027 <+59>:    nop
0x08051028 <+60>:    nop
0x08051029 <+61>:    cmpl   $0x9,0x1c(%esp)
0x0805102e <+66>:    jle    0x8051007 <main+27>
0x08051030 <+68>:    mov    $0x0,%eax
0x08051035 <+73>:    leave
0x08051036 <+74>:    ret
End of assembler dump.
(gdb)

In this system DTrace generates little-endian DOF data, and it looks
like GDB handles it just fine.  I still think the problem you observed
is related to endianness, but I cannot be sure without looking at the
contents of the DOF program embedded in your binaries...