[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