[DTrace-devel] [PATCH v3 1/2] Add support for the print() action

[Alan Maguire]

On 22/11/2023 15:08, Kris Van Hees wrote:
> On Wed, Nov 22, 2023 at 12:47:51PM +0000, Nick Alcock via DTrace-devel wrote:
>> On 22 Nov 2023, Alan Maguire via DTrace-devel verbalised:
> 
> ...
> 
>>> +	if (dt_regset_xalloc_args(drp) == -1)
>>> +		longjmp(yypcb->pcb_jmpbuf, EDT_NOREG);
>>> +	emit(dlp, BPF_MOV_REG(BPF_REG_3, addr->dn_reg));
>>> +	dt_regset_free(drp, addr->dn_reg);
>>> +	emit(dlp, BPF_MOV_REG(BPF_REG_1, BPF_REG_9));
>>> +	emit(dlp, BPF_ALU64_IMM(BPF_ADD, BPF_REG_1, data_off));
>>> +	emit(dlp, BPF_MOV_IMM(BPF_REG_2, size));
>>> +	dt_regset_xalloc(drp, BPF_REG_0);
>>> +	emit(dlp, BPF_CALL_HELPER(BPF_FUNC_probe_read));
>>> +	dt_regset_free_args(drp);
>>> +	dt_regset_free(drp, BPF_REG_0);
>>> +}
>>
>> So this (obviously, sensibly) does no pointer chasing, so this is for
>> printing a single contiguous block of bytes which happens to be a
>> complex aggregate structure? Sounds sensible.
> 
> Interestingly, the Solaris version provides some pointer chasing, for strings.
> That might be something we could add in a 2nd phase (or now if Alan is up for
> it).  The approach they described in email exchanges involved placing the
> strings after the value data block, in the order they appear.  Since the CTF
> data of the entity being dumped is known at the time of compilation that is
> definitely quite doable.  The question is whether it is desirable (or should
> be under some optional argument control (a constant as a flag) or something,
> because it could inflate the data being dumped quite a bit.

Great find; I'll take a look but I'd prefer to defer working on it until
after the initial support lands.  Many of the key kernel data structures
in Linux use embedded char arrays rather than pointers to chars, so it's
probably slightly less needed in Linux (but still a desirable feature).

Thanks!

Alan