From: Peter Bergner <bergner@vnet.ibm.com>
To: Ulrich Weigand <uweigand@de.ibm.com>
Cc: Pedro Alves <palves@redhat.com>, Alan Modra <amodra@gmail.com>,
gdb-patches@sourceware.org,
binutils <binutils@sourceware.org>
Subject: Re: [PATCH, RFC] Add support for choosing disassembler cpu in GDB for POWER.
Date: Fri, 07 Oct 2016 21:01:00 -0000 [thread overview]
Message-ID: <4b819398-85fd-3e91-01cf-dc622b38226b@vnet.ibm.com> (raw)
In-Reply-To: <20161007192106.D516E10C1FE@oc8523832656.ibm.com>
On 10/7/16 2:21 PM, Ulrich Weigand wrote:
>> gdb/
>> * gdbarch.sh (target_disassemble_init): New.
>> * gdbarch.c: Regenerate.
>> * gdbarch.h: Likewise.
>> * disasm.c (gdb_disassemble_info): Call gdbarch_target_disassemble_init.
>> * rs6000-tdep.c: Include "opcode/ppc.h".
>> (gdb_disassembler_cpu): New static declaration.
>> (prospective_cpu): Likewise.
>> (gdb_rs6000_init_disassembly): New function.
>> (set_disassembler_cpu): Likewise.
>> (show_disassembler_cpu): Likewise.
>> (rs6000_gdbarch_init): Setup callback for gdb_rs6000_init_disassembly.
>> (_initialize_rs6000_tdep): Initialize gdb_disassembler_cpu and
>> target_init_disassembly. Setup callbacks for set_disassembler_cpu()
>> and show_disassembler_cpu().
>
> I like this a lot better than the original patch :-)
Heh, well, I'm not a gdb developer, so I don't know the gdb code that
well. I just hacked in stuff that worked with bfd. Now you guys
are forcing me to learn the code and to work hard! :-)
I agree it's looking better too.
> Still some comments:
>
>> @@ -785,6 +785,8 @@ gdb_disassemble_info (struct gdbarch *gdbarch, struct ui_file *file)
>> di.endian = gdbarch_byte_order (gdbarch);
>> di.endian_code = gdbarch_byte_order_for_code (gdbarch);
>> di.application_data = gdbarch;
>> + if (gdbarch_target_disassemble_init_p (gdbarch))
>> + gdbarch_target_disassemble_init (gdbarch, &di);
>> disassemble_init_for_target (&di);
>> return di;
>
> There's a second use of disassemble_init_for_target, which probably needs
> the same treatment. In fact, maybe the nicest way would be to call the
> callback "gdbarch_disassemble_init_for_target", with a default of simply
> disassemble_init_for_target, but which targets can override to do extra
> stuff before (or after) calling disassemble_init_for_target in there.
> GDB common code would then just call gdbarch_disassemble_init_for_target
> everywhere it currently calls disassemble_init_for_target.
Sure, I can give that a try.
>> + gdb_disassembler_cpu = strdup (PPC_DEFAULT_CPU",any");
>
> Why do we have to know about this here in GDB? Can't the GDB default just
> be the empty (or NULL) string, and then opcodes does the defaulting
> (as it does today)?
I thought it would be useful if the user does a "show powerpc disassembler"
without ever doing a "set powerpc disassembler <cpu>" to show them what
default cpu they're actually using. If you want this hunk removed, I
can spit out 'default' in the case gdb_disassembler_cpu is NULL.
Peter
next prev parent reply other threads:[~2016-10-07 21:01 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-30 2:14 Peter Bergner
2016-09-30 17:55 ` Ulrich Weigand
2016-10-03 20:25 ` Peter Bergner
2016-10-03 22:25 ` Alan Modra
2016-10-06 3:00 ` Peter Bergner
2016-10-06 4:44 ` Alan Modra
2016-10-06 9:52 ` Pedro Alves
2016-10-06 19:26 ` Peter Bergner
2016-10-07 19:21 ` Ulrich Weigand
2016-10-07 21:01 ` Peter Bergner [this message]
2016-10-08 14:39 ` Ulrich Weigand
2016-10-10 23:28 ` Peter Bergner
2016-10-12 8:08 ` Ulrich Weigand
2016-10-12 10:46 ` Pedro Alves
2016-10-11 0:09 ` Pedro Alves
2016-10-11 18:49 ` Peter Bergner
2016-10-12 8:25 ` Ulrich Weigand
2016-10-27 0:04 ` Peter Bergner
2016-10-27 9:40 ` Pedro Alves
2016-10-28 13:47 ` Peter Bergner
2016-10-28 14:10 ` Pedro Alves
2016-10-28 14:24 ` Peter Bergner
2016-10-28 14:30 ` Pedro Alves
2016-10-28 14:53 ` Peter Bergner
2016-11-03 11:01 ` Pedro Alves
2016-11-03 15:02 ` Peter Bergner
2016-11-03 15:06 ` Peter Bergner
2016-11-03 16:41 ` Ulrich Weigand
2016-11-03 16:49 ` Peter Bergner
2016-10-28 12:32 ` Ulrich Weigand
2016-10-28 13:45 ` Peter Bergner
2016-10-28 14:15 ` Ulrich Weigand
2016-10-28 15:02 ` Peter Bergner
2016-10-28 18:47 ` Ulrich Weigand
2016-11-02 23:28 ` Peter Bergner
2016-10-12 19:35 ` Pedro Alves
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=4b819398-85fd-3e91-01cf-dc622b38226b@vnet.ibm.com \
--to=bergner@vnet.ibm.com \
--cc=amodra@gmail.com \
--cc=binutils@sourceware.org \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.com \
--cc=uweigand@de.ibm.com \
/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