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: Fri, 7 Aug 2015 08:12:32 -0700
- Subject: Re: [PATCH V4 5/9] New probe type: DTrace USDT probes.
- Authentication-results: sourceware.org; auth=none
- References: <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> <87y4mdjcie dot fsf at oracle dot com> <20150331184727 dot GF13867 at adacore dot com> <878uedey48 dot fsf at oracle dot com> <20150806213103 dot GC14992 at adacore dot com> <874mkb9qv9 dot fsf at oracle dot com> <87k2t7rxmk dot fsf at oracle dot com>
> Confirmed: DOF version 2 added support for is-enabled probes, and the
> struct dtrace_dof_provider got a new 4 bytes field:
>
> @@ -719,6 +722,7 @@ typedef struct dof_provider {
> dof_attr_t dofpv_funcattr; /* function attributes */
> dof_attr_t dofpv_nameattr; /* name attributes */
> dof_attr_t dofpv_argsattr; /* args attributes */
> + dof_secidx_t dofpv_prenoffs; /* link to DOF_SECT_PRENOFFS section */
> } dof_provider_t;
>
> Looks like your solaris-x86 binaries are embedding DOFv1 programs. You
> can check that by looking at dof->dofh_ident[6]: it will be 1 in a DOFv1
> program and 2 in a DOFv2 program.
I think I can confirm that. This is the contents of the .SUNW_dof
section for the .so file:
Contents of section .SUNW_dof:
b4398 7f444f46 01010102 08080000 00000000 .DOF............
^^
||
> So... we can make GDB to look at the DOF version and then use a
> different struct (struct dof_provider_v1 ?) when handling embedded
> programs using the old format.
>
> I can prepare a patch for this. For testing purposes pdtrace can be
> made to generate DOFv1 programs even in systems lacking an old enough
> dtrace.
Sure. I would perhaps also consider the idea of not support DOF v1,
if v1 support is only of marginal value.
Also, I didn't say it before, I wasn't so sure that casting a binary
stream to a structure to read its contents was the best way to do
things. It can of works, but makes the code a little harder to read,
IMO, because accessing its contents requires the accessor macros.
Perhaps it might be better to just have decoding routines that take
the binary data and produce the corresponding struct, with the data
properly decoded. That way, you can add DOF version checks and decode
the data differently, without the rest of the code having to worry
about which version of the type they should be using. It's not obvious
to me that this way is better than the current way, but that's how
I would have tried it first... (just my 2 cents)
--
Joel