From: Peter Bergner <bergner@vnet.ibm.com>
To: Pedro Alves <palves@redhat.com>
Cc: gdb-patches@sourceware.org, Yao Qi <qiyaoltc@gmail.com>,
Alan Modra <amodra@gmail.com>,
Ulrich Weigand <uweigand@de.ibm.com>,
binutils <binutils@sourceware.org>,
Peter Bergner <bergner@vnet.ibm.com>
Subject: Re: [PATCH, v17] Add support for setting disassembler-options in GDB for POWER, ARM and S390
Date: Fri, 24 Feb 2017 04:58:00 -0000 [thread overview]
Message-ID: <98f0a8a0-ed6d-10b6-08be-2dd86cc7af44@vnet.ibm.com> (raw)
In-Reply-To: <3b6b8153-cfff-8fb3-2cc0-2612f3d2d710@redhat.com>
On 2/23/17 6:26 AM, Pedro Alves wrote:
> On 02/22/2017 09:23 PM, Peter Bergner wrote:
>> (gdb) set architecture powerpc:common64
>> The target architecture is assumed to be powerpc:common64
>> (gdb) show disassembler-options
>> The current disassembler options are 'power8'
>> [snip]
>
> Given this was broken but went unnoticed before, something like
> the above should be added as a test.
Done. I added tests for ARM, PowerPC and S390 to verify their options
are preserved over a set architecture call.
>> +/* A macro for iterating over each comma separated option in OPTIONS. */
>> +#define FOR_EACH_DISASSEMBLER_OPTION(OPT, OPTIONS) \
>> + for ((OPT) = (typeof (OPT))(OPTIONS); \
>
> typeof is a GNU extension. I don't see any other use of it in the
> tree. I don't know whether all compilers that binutils intents to
> support accept it.
>
> But why do you need the cast?
I added it because I got a build error due to a cast, but looking
closer, I added an uneeded const on a variable and removing that
obviates the need for the cast. It's removed now. Thanks.
>> + size_t i, num_options = sizeof (ppc_opts) / sizeof (ppc_opts[0]);
>
> While at it, all new occurrences of this
> "sizeof (array) / sizeof (array[0])" idiom should really be
> replaced by "ARRAY_SIZE (array)" instead.
Done.
>> +manual and/or the output of @kbd{objdump --help}. The default value
>> +is empty string.
>
> Missing "the" in "is the empty string".
Fixed.
> While at it, I think it'd be nice to add a ref to the section in binutils
> manual directly. We have a few like that already in the manual. For
> example, we have:
>
> (@pxref{Overlay Description,,, ld.info, Using ld: the GNU linker})
Done.
>> @@ -780,6 +787,7 @@ gdb_disassembler::gdb_disassembler (struct gdbarch *gdbarch,
>> m_di.endian = gdbarch_byte_order (gdbarch);
>> m_di.endian_code = gdbarch_byte_order_for_code (gdbarch);
>> m_di.application_data = this;
>> + m_di.disassembler_options = *gdbarch_disassembler_options (gdbarch);
>
> Isn't this going to crash on archs that don't set gdbarch_disassembler_options?
Ahh, I forgot to test this on one of the unsupported architectures after
I made the change of the gdbarch_disassembler_options to char **.
Yes, it dies. I added a new function get_disassembler_options() that
we can use, which will do the dereference for us, but only if the
arch is supported. Otherwise, it returns NULL. That fixes the SEGVs.
> Do the "gdb.base/all-architectures-*.exp" tests pass on an
> --enable-targets=all build of gdb with this patch?
I think I cleaned out my last build, so I can't check.
With the issues above and below fixed, they do all pass.
>> + for (i = 0, col = 0; valid_options->name[i] != NULL; i++)
>> + {
>> + /* Include the " " and "," we print below. */
>> + size_t len = strlen (valid_options->name[i]) + 2;
>> + if (col + len > 80)
>
> Is this 80 here supposed to be the screen width? Do we
> really need this manual wrapping?
The only architecture that uses this is the ppc arch and this mimics
what print_ppc_disassembler_options() does. We have ~60 options that
we're emitting, so I think wrapping does make things more readable.
>> +/* Holds the current set of options to be passed to the disassembler. */
>> +static char *disassembler_options;
>
> Even though these are going to be statics, can you please name
> them $cpu_disassembler_options, etc. It'll make debugging
> gdb easier. "(gdb) print arm_disassembler_options", etc.
Done.
>> + len = strcspn(style, ",");
>
> missing space before parens.
Fixed.
I'll post the new patch. Thanks.
Peter
next prev parent reply other threads:[~2017-02-24 4:58 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-22 21:23 Peter Bergner
2017-02-23 12:26 ` Pedro Alves
2017-02-24 4:58 ` Peter Bergner [this message]
2017-02-24 15:06 ` Pedro Alves
2017-02-24 17:13 ` Peter Bergner
2017-02-24 17:25 ` Pedro Alves
2017-02-24 17:28 ` Peter Bergner
2017-02-28 11:24 ` Yao Qi
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=98f0a8a0-ed6d-10b6-08be-2dd86cc7af44@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=qiyaoltc@gmail.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