[DTrace-devel] [PATCH 3/6] build: add gdb and valgrind support to the run-dtrace wrapper

[Nick Alcock]

On 15 May 2023, Kris Van Hees stated:

> On Fri, May 12, 2023 at 10:19:04AM -0400, Kris Van Hees wrote:
>> On Fri, May 12, 2023 at 10:07:40AM -0400, Kris Van Hees via DTrace-devel wrote:
>> > On Wed, Apr 19, 2023 at 04:41:28PM +0100, Nick Alcock via DTrace-devel wrote:
>> > > Now, rather than having to mess around setting SYSLIBDIR and
>> > > LD_LIBRARY_PATH yourself to debug a just-built dtrace, you can
>> > > just run DTRACE_GDB=t build/run-dtrace or
>> > > DTRACE_VALGRIND=t build/run_dtrace
>
> run_dtrace -> run-dtrace
>
>> > > 
>> > > GDB is run with --args. Valgrind is run with no args other that the
>> > > just-built dtrace's for now.
>> > > 
>> > > Signed-off-by: Nick Alcock <nick.alcock at oracle.com>
>> > 
>> > Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>
>> 
>> Actually, withdrawn... see below
>> 
>> > ... with one change...  THe run-dtrace script should now use
>> > 
>> > 	#!/usr/bin/bash
>> > 
>> > instead of
>> > 
>> > 	#!/bin/sh
>> > 
>> > because e.g. on Debian the default /bin/dh is *not* bash and you are now
>> > using a bash construct.
>> 
>> I was too hasty...  In this patch you actually provide support for gdb
>> and valgrind, but they make use of the *installed* dtrace even though
>> the script puts the support for them in the not-installed codepath.  That
>> makes no sense.

What?!!

... oh god I'm an idiot.

Will fix obvious typo :)

>> I'd suggest adding support for gdb and valgrind in *both* branches of the
>> conditional, one for non-installed (i.e. in-tree) dtrace and one for
>> installexd dtrace.  Which you can then probably handle better by having the
>> conditional handle the setting of the env vars and the full pathname for
>> dtrace, and then further in the script simmply have the conditionals for
>> gdb or valgrind (or neither) and invoke dtrace.  Less duplication that way.

Indeed.