This is the mail archive of the
mailing list for the binutils project.
RE: [PATCH] [ARC] Pass arc_opcode to GDB as an architecture specific data
- From: Anton Kolesov <Anton dot Kolesov at synopsys dot com>
- To: Yao Qi <qiyaoltc at gmail dot com>
- Cc: "binutils at sourceware dot org" <binutils at sourceware dot org>, Francois Bedard <Francois dot Bedard at synopsys dot com>, Claudiu Zissulescu <Claudiu dot Zissulescu at synopsys dot com>, Cupertino Miranda <Cupertino dot Miranda at synopsys dot com>
- Date: Thu, 6 Oct 2016 12:51:54 +0000
- Subject: RE: [PATCH] [ARC] Pass arc_opcode to GDB as an architecture specific data
- Authentication-results: sourceware.org; auth=none
- References: <1475256804-22812-1-git-send-email-Anton.Kolesov@synopsys.com> <CAH=s-PNSB_GQ51_-xrSWd5Ngk3Z+ic5PrYhgVWqzNESTgZuytQ@mail.gmail.com>
> On Fri, Sep 30, 2016 at 6:33 PM, Anton Kolesov
> <Anton.Kolesov@synopsys.com> wrote:
> > To do prologue analysis GDB needs to know a lot of information about
> > instructions that is not provided by generic disassemble_info structure.
> > example, disassemble_info doesn't provide information about instruction
> > operands, or whether instruction is has is a predicated (which means that it
> > effectively a branch and in general prologue analysis halts immediately on
> > branches). To close the information gap between disassembly and GDB it is
> > required to pass architecture-specific structure "arc_opcode" to GDB as a
> > of "private_data" field of disassemble_info structure. Structure
> > contains most of the information needed by GDB.
> How do you use disassemble_info in prologue analysis? I am not sure
> disassemble_info can be used for something other than disassembly.
disassemble_info itself is indeed not useful for instruction analysis, so I use
it only as a vehicle to gain access to a target-dependent arc_opcode.
> > Alternative solution would be to do a complete instruction decoding in GDB
> > instead of using opcodes, however that would create a lot of unnecessary
> > duplication, which would be especially problematic because ARC doesn't have
> > clear instruction encoding format organization, so handling all of the
> > instruction formats is quite a task.
> Right, alternatively, you can add a new api, like arc_decode_insn, and it
> returns structure "arc_opcode", so that GDB can use it in prologue
> analysis and somewhere else if instruction decoding is needed. We
> did the same in aarch64, see how aarch64_decode_insn is used in
That's what I wanted to get - something similar to aarch64_decode_insn, but
ARC binutils developers didn't wanted to do things this way, and told me
instead to use arc_get_disassembler() which returns pointer to a
print_insn_arc(). Given the imposed constraints, I've preferred to do this
one-line change to binutils and put the rest of instruction decoding in
the GDB proper, to minimize binutils changes. arc_opcode itself is bit
problematic in this context because it is optimized for instruction printing
and not for instruction analysis, but it is still much better than trying to
write disassembler from the scratch. My corresponding GDB patch is currently
pending on this patch to be approved before I will submit it to gdb-patches,
and it basically just adds an another abstraction layer - it parses arc_opcode
structure and creates and another structure that is more suitable for
instruction analysis needed in prologue scanning.
> Yao (齐尧)