On 11/10/25 8:47 AM, Mark Wielaard wrote:
Hi,
OK. Let me try to summarize the proposal(s) and choices so we have
something concrete to discuss in the DWARF Committee meeting this
afternoon.
- Clarify what DW_OP_mod means on generic types.
This doesn't seem to need extra/explicit clarification because
2.5.1.4 "Arithmetic and Logical Operations" says:
If the type of the operands is the generic type, except as otherwise
speciļ¬ed, the arithmetic operations perform addressing arithmetic,
that is, unsigned arithmetic that is performed modulo one plus the
largest representable address.
[This formulation might need some tweaking if there are multiple
address spaces with different representable addresses. But IMHO
that can wait for another time.]
- Define DW_OP_mod for integral (possibly signed) typed DWARF values.
There are a couple of choices of how to define this for (signed)
typed values. But the most "natural" way would be using either
floored or truncated division. Lets pick floored division?
I would argue for truncated division for DW_OP_mod
- Mention backward compatibility of the choice. If we assume producers
work like Jakub showed for GCC (where DW_OP_mod is only used for
unsigned/generic types) then there is no issue if we define it for
integral (signed) types.
agreed.
For GDB there might be some assumption it
would be modulo using floored division.
Yes it breaks GDB's current implementation but other consumers have
interpreted it as truncated division. If you add DW_OP_modulo, GDB's
current implementation could be used for that and DW_OP_mod could be
implemented with % like it is in other consumers.
But in general it seems
our choice would just mean that consumers should explicitly implement
DW_OP_mod for typed DWARF vales as specified.
- Rename DW_OP_mod to DW_OP_rem? And/Or introduce a new DW_OP_modulo.
If the implementation choice is not "true" modulo should we give
the DW_OP_mod a new name? IMHO No. It really is too confusing.
mod(ulo) and rem(ainder) are already not consistently used in
different languages.
I like what Cary pointed out about Fortran MOD for truncated division
and then MODULO for floored. I think that is the best choice. As long as
the algorithm is specified in the description, and given Fortran's prior
usage, I no longer think we need to change the name.
- Add a new DW_OP_rem that uses truncated (if we pick floored for mod)
division? If yes then we should explicitly mention this shouldn't
be used for 6.4.2 Call Frame Instructions (it would be redundant
with DW_OP_mod anyway for the generic type).
- Should this new DW_OP_rem be an extended DW_OP?
I would say DW_OP_modulo (floored) should be the one considered for
being an extended op. I don't have very strong opinion on this. Slightly
more than "whatever".
- Extend DW_OP_mod (and DW_OP_rem) to float types?
That is the original proposal, changing 2.5.1.4 ("Operations other
than DW_OP_abs, DW_OP_div, DW_OP_minus, DW_OP_mul, DW_OP_neg and
DW_OP_plus require integral types of the operand").
I admit to not really know how to define this or if the mod/rem
operation is "simply" dictated by the the DW_ATE_*float* definitions.
Also, is it really needed?
I believe that it is needed to be able to create implicit storage for
floating point values optimized out real storage. ref:
https://dwarfstd.org/issues/140425.1.html
Hope that is a good summary of the proposals/choices we have to make.
Cheers,
Mark
--
Dwarf-discuss mailing list
[email protected]
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
