On Tue, Nov 15, 2016 at 04:00:40PM +0000, Jiong Wang wrote:
> >> Takes one signed LEB128 offset and retrieves 8-byte contents from the
> >> address
> >> calculated by CFA plus this offset, the contents then authenticated as
> >> per A
> >> key for instruction pointer using current CFA as salt. The result is
> >> pushed
> >> onto the stack.
> >I'd like to point out that especially the vendor range of DW_OP_* is
> >extremely scarce resource, we have only a couple of unused values, so taking
> >3 out of the remaining unused 12 for a single architecture is IMHO too much.
> >Can't you use just a single opcode and encode which of the 3 operations it is
> >in say the low 2 bits of a LEB 128 operand?
> >We'll likely need to do RSN some multiplexing even for the generic GNU
> >opcodes if we need just a few further ones (say 0xff as an extension,
> >followed by uleb128 containing the opcode - 0xff).
> >In the non-vendor area we still have 54 values left, so there is more space
> >for future expansion.
>
> Seperate DWARF operations are introduced instead of combining all of them
> into
> one are mostly because these operations are going to be used for most of the
> functions once return address signing are enabled, and they are used for
> describing frame unwinding that they will go into unwind table for C++ program
> or C program compiled with -fexceptions, the impact on unwind table size is
> significant. So I was trying to lower the unwind table size overhead as much
> as
> I can.
>
> IMHO, three numbers actually is not that much for one architecture in DWARF
> operation vendor extension space as vendors can overlap with each other. The
> only painful thing from my understand is there are platform vendors, for
> example
> "GNU" and "LLVM" etc, for which architecture vendor can't overlap with.
For DW_OP_*, there aren't two vendor ranges like e.g. in ELF, there is just
one range, so ideally the opcodes would be unique everywhere, if not, there
is just a single GNU vendor, there is no separate range for Aarch64, that
can overlap with range for x86_64, and powerpc, etc.
Perhaps we could declare that certain opcode subrange for the GNU vendor is
architecture specific and document that the meaning of opcodes in that range
and count/encoding of their arguments depends on the architecture, but then
we should document how to figure out the architecture too (e.g. for ELF
base it on the containing EM_*). All the tools that look at DWARF (readelf,
objdump, eu-readelf, libdw, libunwind, gdb, dwz, ...) would need to agree on
that
though.
I know nothing about the aarch64 return address signing, would all 3 or say
2 usually appear together without any separate pc advance, or are they all
going to appear frequently and at different pcs? Perhaps if there is just 1
opcode and has all the info encoded just in one bigger uleb128 or something
similar...
Jakub
