[DTrace-devel] [PATCH 30/38] Allow relocation on BPF_OR instructions

Eugene Loh eugene.loh at oracle.com
Mon Sep 30 22:00:40 UTC 2024


On 9/30/24 17:19, Kris Van Hees wrote:

> On Fri, Jul 19, 2024 at 05:34:17PM -0400, Kris Van Hees wrote:
>> On Thu, Jun 27, 2024 at 01:38:56AM -0400, eugene.loh at oracle.com wrote:
>>> From: Eugene Loh <eugene.loh at oracle.com>
>>>
>>> Signed-off-by: Eugene Loh <eugene.loh at oracle.com>
>> Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>
> As far as I can see, there is nothing that uses this anymore.

Yes.  As best as I can remember, that's right.

> I suggest we
> ut it in cold storage until there is a need for it?

Sounds great.

> Alternatively, we could
> turn this into a patch that adds support for all possible operations that
> could require relocations like this, and introduce that to the tree instead
> to support future uses.

Meh.

>>> ---
>>>   libdtrace/dt_as.c | 2 ++
>>>   1 file changed, 2 insertions(+)
>>>
>>> diff --git a/libdtrace/dt_as.c b/libdtrace/dt_as.c
>>> index a634b855..4b397f51 100644
>>> --- a/libdtrace/dt_as.c
>>> +++ b/libdtrace/dt_as.c
>>> @@ -280,6 +280,7 @@ dt_as(dt_pcb_t *pcb)
>>>   		case BPF_ST | BPF_MEM | BPF_DW:		/* stdw */
>>>   		case BPF_ALU64 | BPF_MOV | BPF_K:	/* mov */
>>>   		case BPF_ALU64 | BPF_ADD | BPF_K:	/* add */
>>> +		case BPF_ALU64 | BPF_OR  | BPF_K:	/* or */
>>>   			if (idp->di_flags & DT_IDFLG_BPF)
>>>   				brel++;
>>>   			else
>>> @@ -492,6 +493,7 @@ fail:
>>>   			case BPF_ST | BPF_MEM | BPF_DW:		/* stdw */
>>>   			case BPF_ALU64 | BPF_MOV | BPF_K:	/* mov */
>>>   			case BPF_ALU64 | BPF_ADD | BPF_K:	/* add */
>>> +			case BPF_ALU64 | BPF_OR  | BPF_K:	/* or */
>>>   				rp->dofr_type = R_BPF_64_32;
>>>   				break;
>>>   			case BPF_LD | BPF_IMM | BPF_DW:		/* lddw */
>>> -- 
>>> 2.18.4
>>>



More information about the DTrace-devel mailing list