[Dwarf-discuss] Clarification: DW_OP_mod doesn't specify which definition of modulo

[Ben Woodard]

<comments inline>

On 11/7/25 6:58 AM, Mark Wielaard wrote:
> Hi Ben,
>
> On Thu, 2025-11-06 at 11:34 -0800, Ben Woodard via Dwarf-discuss wrote:
>> On 11/6/25 9:46 AM, Mark Wielaard via Dwarf-discuss wrote:
>>
>> Given what I now know and the problem that you pointed out with CFI.
>> I think that I would suggest:
>>
>> Rename DW_OP_mod to DW_OP_rem in DWARF6 and then specify that it uses
>> truncated division so that it follows the semantics of C99's % operator
>> for signed and unsigned types. This would minimize the implementation
>> difficulty for most consumers. This should be backward compatible with
>> existing usage because of the undocumented limitation on the domain of
>> DW_OP_mod. If people feel there is a need, it can also be extended to
>> support floating point types.
>>
>> Then if the committee feels that it is useful to have a true modulo function,
>> they could also add a DW_OP_modulo which uses floored division from Knuth.
> I think renaming is really confusing. And I think extending to
> supporting floating point types should be a separate issue that would
> also look at the other operators.
>
> Maybe a compromise would be to keep DW_OP_mod (and make DW_OP_rem an
> alias?)

I would do it the other way around make DW_OP_mod be a legacy alias and 
call the same operation DW_OP_rem.

We are already renaming a bunch of operators to give them more 
appropriate names and keeping the old names as aliases (and we are 
already going to be renaming a bunch more to make them more accurately 
reflect what they do) and so there is precedent for this. e.g. 
DW_OP_push_object_address became the more appropriately named 
DW_OP_push_object_location

> which is only defined for use with (unsigned) generic type
> values.

With Jakub's example, I think that we have a compelling reason to expand 
the domain of DW_OP_rem (the former DW_OP_mod) to include signed 
integral types as well as unsigned integral types. His example seems to 
require the semantics of C99's % operator (truncated division).

If we do this, then it will be backward compatible. The only thing that 
we would be changing is the domain over which the current DW_OP_mod 
operates. We are not changing any of the semantics.

I'm ambivalent about expanding the domain to floating point values. If 
someone has a reason for having it work on floating point types, then 
sure why not. It is a bit of extra code in every consumer but whatever.

What I really care about is that when we update the description of 
DW_OP_rem (the operation formerly known as  DW_OP_mod) we specify both 
the domain of the operator as well as the algorithm used.

>   Then introduce new DW_OP_modulo (defined using floored
> division)
Again I'm personally ambivalent about the need for this. I don't think 
that it is going to be used very often and I think if we do define it we 
should consider pushing it into the new DW_OP_extended operation 
encoding space. This will make its encoding a two byte operation but it 
will reserve more of the one byte encodings for more frequently used 
operations.
> and DW_OP_remainder (defined using truncated division)
> operators that are only to be used with typed DWARF stack values?

I really do believe that a better approach is to rename and expand the 
domain of the current DW_OP_mod rather than adding another new special 
purpose operator.

-ben

>
> Cheers,
>
> Mark
>