https://sourceware.org/bugzilla/show_bug.cgi?id=32613
Bug ID: 32613
Summary: .cfi_escape usability
Product: binutils
Version: 2.45 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: jbeulich at suse dot com
Target Milestone: ---
Documentation specifically says "One might use this to add OS-specific CFI
opcodes, or generic CFI opcodes that GAS does not yet support." With many
DW_CFA_* taking LEB128 operands, how would one go about encoding their operands
through .cfi_escape? All it processes is a byte sequence, so right now the only
option appears to be to hand-encode the operand(s). Which in turn requires them
to either be constants, or to involve perhaps pretty complex expressions.
A possible extension to what's presently permitted might be
.cfi_escape <expr1>, uleb128(<expr2>), sleb128(<expr3>), ...
That shouldn't conflict with existing uses, as the 2nd and 3rd operands don't
themselves form valid expressions.
Of course non-LEB128, non-byte operands may also occur (like for
DW_CFA_advance_loc<N>). When they require a relocation of the respective width,
those cannot be decomposed into byte sequences. Therefore granularity of the
individual operands also wants to be specifiable. Maybe
.cfi_escape <expr1>, u32(<expr2>), s16(<expr3>), ...
and to allow code to not directly encode address width in source
.cfi_escape <expr1>, uaddr(<expr2>), saddr(<expr3>), ...
I wonder if it might even be necessary to allow specifying non-default
endian-ness for such (hopefully not).
Thoughts anyone?
--
You are receiving this mail because:
You are on the CC list for the bug.
