Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Anton Kolesov <Anton.Kolesov@synopsys.com>
To: Simon Marchi <simon.marchi@polymtl.ca>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
	Francois Bedard	<Francois.Bedard@synopsys.com>
Subject: RE: [PATCH] arc: Select CPU model properly before disassembling
Date: Tue, 06 Jun 2017 13:51:00 -0000	[thread overview]
Message-ID: <39A54937CC95F24AA2F794E2D2B66B135874F238@DE02WEMBXB.internal.synopsys.com> (raw)
In-Reply-To: <64a77ae925bca53fed60b579642f07f8@polymtl.ca>

Hi Simon

> >
> > 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
 
> Hi Anton,
> 
> This is not very clear to me (I haven't really touched disassembly yet),
> so let me train to summarize the situation.  Let's say you feed the
> right executable to GDB, but connect to a gdbserver that doesn't report
> the cpu arch in the target description.  arc_disassembler_options won't
> be set, so we won't pass an explicit disassembler option.  opcodes
> internals could try to fall back on data from the BFD if
> disassemble_info::section was set.  However, this is only done in
> arc_delayed_print_insn, which is not used in that case (it was removed
> as a gdbarch callback in commit [2]).  Does that sound right?

Yes, your understanding is correct. For ARC this change will not be a
regression, because today disassembler never selects properly between ARC EM
and HS at all cases - this patch will fix some cases, but not the others, that
why I feel this makes sense.

> 
> Could gdb_disassembler set the section field of disassemble_info itself?
>   What you are doing to set the section field here is not ARC-specific,
> it looks like it could potentially help other architectures to have that
> field set.
> 
> Other places that use the disassembler would have to set it too, for
> example in the object prepared by the arc_disassemble_info function.

I think this info->section initialization code can be moved to
arch-utils.c:default_print_insn, however I'm not sure if that wouldn't cause
any troubles with other architectures. Doing initialization in gdb_disassembler
constructor is complicated, because we don't really know what would be the
disassembled address at this stage, hence what would be the section.
Gdb_dissassembler construction can use .text section as a default, but then
might now work with some multi-arch ELFs, I presume (unlikely to be a
problem for ARC, though).

Another option is, of course, to partially revert [2] for ARC - make
arc_delayed_print_insn a printer for ARC, but change it, so it will only
set info->section and then call default_print_insn. I believe that same change
is needed in mep-tdep.c. At least for ARC we would need to use print_insn
anyway to disassemble, because opcodes/arc-dis.c:arc_insn_decode relies on it.

> > +	  std::string disasm_options
> > +	    = string_printf ("cpu=%s", tdesc_arch->printable_name);
> > +	  arc_disassembler_options = xstrdup (disasm_options.c_str ());
> 
> You could shorten this by using xstrprintf directly.

Will do in v2.

Anton

> 
> > +	  set_gdbarch_disassembler_options (gdbarch,
> > +					    &arc_disassembler_options);
> > +	}
> > +    }
> > +
> >    tdesc_use_registers (gdbarch, tdesc, tdesc_data);
> >
> >    return gdbarch;
> 
> This part, which sets the disassembler options based on the target
> description, looks good to me.
> 
> Simon


  reply	other threads:[~2017-06-06 13:51 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-01 16:02 Anton Kolesov
2017-06-05 20:07 ` Simon Marchi
2017-06-06 13:51   ` Anton Kolesov [this message]
2017-06-13 13:49     ` [PATCH v2] " Anton Kolesov
2017-06-13 22:16       ` Simon Marchi
     [not found]         ` <39A54937CC95F24AA2F794E2D2B66B1358756E48@DE02WEMBXB.internal.synopsys.com>
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=39A54937CC95F24AA2F794E2D2B66B135874F238@DE02WEMBXB.internal.synopsys.com \
    --to=anton.kolesov@synopsys.com \
    --cc=Francois.Bedard@synopsys.com \
    --cc=gdb-patches@sourceware.org \
    --cc=simon.marchi@polymtl.ca \
    /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