This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH V4 5/9] New probe type: DTrace USDT probes.
- From: jose dot marchesi at oracle dot com (Jose E. Marchesi)
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: Sergio Durigan Junior <sergiodj at redhat dot com>, gdb-patches at sourceware dot org
- Date: Tue, 31 Mar 2015 19:35:37 +0200
- Subject: Re: [PATCH V4 5/9] New probe type: DTrace USDT probes.
- Authentication-results: sourceware.org; auth=none
- References: <1422874968-382-1-git-send-email-jose dot marchesi at oracle dot com> <1422874968-382-6-git-send-email-jose dot marchesi at oracle dot com> <87r3tp722i dot fsf at redhat dot com> <20150325191418 dot GA32233 at adacore dot com> <87bnjfraq1 dot fsf at oracle dot com> <20150326175028 dot GA13867 at adacore dot com>
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...