This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]