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?
- 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. For GDB there might be some assumption it
would be modulo using floored division. 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.
- 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?
- 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?
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