[DTrace-devel] [PATCH v3 03/19] cg: fault improvements
Eugene Loh
eugene.loh at oracle.com
Tue Mar 29 16:38:08 UTC 2022
On 3/29/22 7:14 AM, Nick Alcock via DTrace-devel wrote:
> On 29 Mar 2022, Kris Van Hees spake thusly:
>
>> On Thu, Mar 24, 2022 at 06:24:29PM +0000, Nick Alcock via DTrace-devel wrote:
>>> Add a label to dt_cg_probe_error, which is dropped on the first
>>> instruction if set; eschew regset allocation on the grounds that
>>> spilling to the stack is pointless when the regs will all be thrown away
>>> in any case, and can trigger errors if some of the regs are not properly
>>> initialized, as is relatively likely in an error condition.
>>>
>>> Also add a new dt_cg_probe_error_regval, which is like dt_cg_probe_error
>>> except the last argument is not an illegal value but a register whose
>>> value should be emitted. This is a bit trickier: we must move the
>>> illegal register arg into place first because we don't use the regset
>>> allocation code, so it might be using one of the regs we're about to
>>> overwrite; and don't emit a move at all if we're by chance already using
>>> that reg (the verifier doesn't like mov %r4, %r4 very much).
>> How about renaming dt_cg_probe_error_regval() to be dt_cg_probe_error_reg()
>> and rename dt_cg_probe_error() to be dt_cg_probe_error_imm(), to match the
>> BPF instructions (*_IMM vs *_REG). That emphesises the distinct even better.
> I already changed this after Eugene's suggestions, to a single
> dt_cg_probe_error() which takes an isreg arg. It makes a number of
> failing code paths easier to follow.
>
>> Further, I am not sure that there is enough value to adding a label argument to
>> the dt_cg_probe_error_*() calls. There are only 4 such calls in the remainder
>> of this patch series, and those are 2 sets of conditional-controlled pairs of
>> calls. As such, you could as easily place a BPF_NOP() with a label before
>> each conditional clause. I think that would also make those uses more clear
>> in the calling functions.
> ... I thought we were trying to save instructions? Are we not any more?
> I was trying to keep the number of pointless NOPs down...
I thought we discussed this already. Labeled NOPs do not end up in the
instruction stream. Check dt_irlist_append(). There is a check:
if (dip->di_label == DT_LBL_NONE || !BPF_IS_NOP(dip->di_instr))
dlp->dl_len++;
So if you have a label and the instruction is a NOP, you don't keep the
instruction.
More information about the DTrace-devel
mailing list