This is the mail archive of the
mailing list for the binutils project.
Re: [1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Jiong Wang <jiong dot wang at foss dot arm dot com>, mjw at tucnak dot zalov dot cz
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>, gdb-patches at sourceware dot org, Binutils <binutils at sourceware dot org>, "Richard Earnshaw (lists)" <Richard dot Earnshaw at arm dot com>
- Date: Tue, 15 Nov 2016 17:18:17 +0100
- Subject: Re: [1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space
- Authentication-results: sourceware.org; auth=none
- References: <email@example.com> <firstname.lastname@example.org> <20161111193859.GJ3541@tucnak.redhat.com> <email@example.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
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
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