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: Thu, 26 Mar 2015 17:21:10 +0100
- 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>
Hi Joel!
> > + /* Try to parse a type expression from the type string. If
> > + this does not work then we set the type to `long
> > + int'. */
> > + arg.type = builtin_type (gdbarch)->builtin_long;
> > + expr = parse_expression (arg.type_str);
^^^^^^^^^^^^^^^^
there
The most obvious issue is that type "mutex_t" does not exist in
my program, so I think that the code should handle that case.
Certainly.
The second, less obvious issue, is that the parsing is done using
the current language, which I don't think is a good idea. Attached
is small prototype that attempts to do something like that.
I think we need a function that parses an expression using
a specific language, but I went for short prototype to test
my theory first.
That solves most of the issues, even if I don't really know if
it's not just sweeping them under the carpet instead.
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...
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?
Salud!