Re: [PATCH V4 5/9] New probe type: DTrace USDT probes.

[jose.marchesi@oracle.com (Jose E. Marchesi)]

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...