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: Joel Brobecker <brobecker at adacore dot com>
- To: "Jose E. Marchesi" <jose dot marchesi at oracle dot com>
- Cc: Sergio Durigan Junior <sergiodj at redhat dot com>, gdb-patches at sourceware dot org
- Date: Thu, 26 Mar 2015 10:50:28 -0700
- 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>
> Well, the TRY..CATCH in your prototype would catch any error that may be
> thrown in parse_expression, and the `set_language' must take care of
> changing the language, so I would say that is enough...
OK - I will send an updated patch that makes things a little cleaner.
I didn't know whether it was OK to default to type long makes much
sense when the probe says the parameter should be using type "mutex_t".
> 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. How do you think we should proceed?
Thanks!
--
Joel