From: Anton Kolesov <Anton.Kolesov@synopsys.com>
To: gdb-patches@sourceware.org
Cc: Anton Kolesov <Anton.Kolesov@synopsys.com>,
Francois Bedard <Francois.Bedard@synopsys.com>
Subject: [PATCH v2] arc: Select CPU model properly before disassembling
Date: Tue, 13 Jun 2017 13:49:00 -0000 [thread overview]
Message-ID: <20170613134951.29359-1-Anton.Kolesov@synopsys.com> (raw)
In-Reply-To: <39A54937CC95F24AA2F794E2D2B66B135874F238@DE02WEMBXB.internal.synopsys.com>
Changes in V2:
* Use xstrprintf instead of string_printf
* Reinstate arc_delayed_print_insn as a print instruction function for ARC.
* Change arc_delayed_print_insn to use default_print_insn.
* Change commit description accordingly.
---
Enforce CPU model for disassembler via its options, if it was specified in XML
target description, otherwise use default method of determining CPU implemented
in disassembler - scanning ELF private header. The latter requires
disassemble_info->section to be properly initialized. To make sure that
info->section is set in all cases this patch partially reverts [1] for ARC: it
reinstates arc_delayed_print_insn as a "print_insn" function for ARC, but
now this function only sets disassemble_info->section and then calls
default_print_insn to do the rest of the job.
Support for CPU in disassembler options for ARC has been added in [2].
[1] https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=39503f82427e22ed8e04d986ccdc8562091ec62e
[2] https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=10045478d984f9924cb945423388ba25b7dd3ffe
gdb/ChangeLog:
yyyy-mm-dd Anton Kolesov <anton.kolesov@synopsys.com>
* arc-tdep.c (arc_disassembler_options): New variable.
(arc_gdbarch_init): Set and use it. Use arc_delayed_print_insn instead
of default_print_insn.
(arc_delayed_print_insn): Set info->section when needed,
use default_print_insn to retrieve a disassembler.
---
gdb/arc-tdep.c | 51 +++++++++++++++++++++++++++++++++++++++++++++------
1 file changed, 45 insertions(+), 6 deletions(-)
diff --git a/gdb/arc-tdep.c b/gdb/arc-tdep.c
index d9ee5c6..9a5efc1 100644
--- a/gdb/arc-tdep.c
+++ b/gdb/arc-tdep.c
@@ -145,6 +145,8 @@ static const char *const core_arcompact_register_names[] = {
"lp_count", "reserved", "limm", "pcl",
};
+static char *arc_disassembler_options = NULL;
+
/* Functions are sorted in the order as they are used in the
_initialize_arc_tdep (), which uses the same order as gdbarch.h. Static
functions are defined before the first invocation. */
@@ -1405,12 +1407,31 @@ arc_skip_prologue (struct gdbarch *gdbarch, CORE_ADDR pc)
int
arc_delayed_print_insn (bfd_vma addr, struct disassemble_info *info)
{
- int (*print_insn) (bfd_vma, struct disassemble_info *);
- /* exec_bfd may be null, if GDB is run without a target BFD file. Opcodes
- will handle NULL value gracefully. */
- print_insn = arc_get_disassembler (exec_bfd);
- gdb_assert (print_insn != NULL);
- return print_insn (addr, info);
+ /* Standard BFD "machine number" field allows libocodes disassembler to
+ distinguish ARC 600, 700 and v2 cores, however v2 encompasses both ARC EM
+ and HS, which have some difference between. There are two ways to specify
+ what is the target core:
+ 1) via the disassemble_info->disassembler_options;
+ 2) otherwise libopcodes will use private (architecture-specific) ELF
+ header.
+
+ Using disassembler_options is preferable, because it comes directly from
+ GDBserver which scanned an actual ARC core identification info. However,
+ not all GDBservers report core architecture, so as a fallback GDB still
+ should support analysis of ELF header. The libopcodes disassembly code
+ uses the section to find the BFD and the BFD to find the ELF header,
+ therefore this function should set disassemble_info->section properly.
+
+ disassembler_options was already set by non-target specific code with
+ proper options obtained via gdbarch_disassembler_options (). */
+ if (info->disassembler_options == NULL)
+ {
+ struct obj_section * s = find_pc_section (addr);
+ if (s != NULL)
+ info->section = s->the_bfd_section;
+ }
+
+ return default_print_insn (addr, info);
}
/* Baremetal breakpoint instructions.
@@ -2013,6 +2034,8 @@ arc_gdbarch_init (struct gdbarch_info info, struct gdbarch_list *arches)
set_gdbarch_frame_align (gdbarch, arc_frame_align);
+ set_gdbarch_print_insn (gdbarch, arc_delayed_print_insn);
+
set_gdbarch_cannot_step_breakpoint (gdbarch, 1);
/* "nonsteppable" watchpoint means that watchpoint triggers before
@@ -2041,6 +2064,22 @@ arc_gdbarch_init (struct gdbarch_info info, struct gdbarch_list *arches)
if (tdep->jb_pc >= 0)
set_gdbarch_get_longjmp_target (gdbarch, arc_get_longjmp_target);
+ /* Disassembler options. Enforce CPU if it was specified in XML target
+ description, otherwise use default method of determining CPU (ELF private
+ header). */
+ if (info.target_desc != NULL)
+ {
+ const struct bfd_arch_info *tdesc_arch
+ = tdesc_architecture (info.target_desc);
+ if (tdesc_arch != NULL)
+ {
+ arc_disassembler_options = xstrprintf ("cpu=%s",
+ tdesc_arch->printable_name);
+ set_gdbarch_disassembler_options (gdbarch,
+ &arc_disassembler_options);
+ }
+ }
+
tdesc_use_registers (gdbarch, tdesc, tdesc_data);
return gdbarch;
--
2.8.3
next prev parent reply other threads:[~2017-06-13 13:49 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-01 16:02 [PATCH] " Anton Kolesov
2017-06-05 20:07 ` Simon Marchi
2017-06-06 13:51 ` Anton Kolesov
2017-06-13 13:49 ` Anton Kolesov [this message]
2017-06-13 22:16 ` [PATCH v2] " Simon Marchi
2017-06-14 14:02 ` Anton Kolesov
2017-06-14 16:27 ` Simon Marchi
2017-06-14 16:37 ` Pedro Alves
2017-06-15 13:20 ` Anton Kolesov
2017-06-15 13:20 ` [PATCH v3] " Anton Kolesov
2017-06-15 21:12 ` Simon Marchi
2017-06-16 12:03 ` Anton Kolesov
2017-06-13 21:31 ` [PATCH] " Simon Marchi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170613134951.29359-1-Anton.Kolesov@synopsys.com \
--to=anton.kolesov@synopsys.com \
--cc=Francois.Bedard@synopsys.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).