From: Alan Hayward <Alan.Hayward@arm.com>
To: Simon Marchi <simark@simark.ca>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
nd <nd@arm.com>
Subject: Re: [PATCH v5 1/8] Commonise tdesc_reg
Date: Wed, 18 Apr 2018 09:03:00 -0000 [thread overview]
Message-ID: <41D75C72-120B-4EEC-BAA5-D48232DD51ED@arm.com> (raw)
In-Reply-To: <633ee25e-6f5e-5747-1f5d-8c86fafd19dd@simark.ca>
> On 18 Apr 2018, at 02:57, Simon Marchi <simark@simark.ca> wrote:
>
> On 2018-04-10 10:33 AM, Alan Hayward wrote:
>> This patch commonises tdesc_reg and makes use of it in gdbserver tdesc.
>>
>> gdbserver tdesc_create_reg is changed to create a tdesc_reg instead of
>> a reg_defs entry. The vector of tdesc_reg is held inside tdesc_feature.
>>
>> However, other modules in gdbserver directly access the reg_defs structure.
>> To work around this, init_target_desc fills in reg_defs by parsing the
>> tdesc_reg vector.
>> The long term goal is to remove reg_defs, replacing with accessor funcs.
>>
>> I wanted to make tdesc_create_reg common, but I cannot do that until
>> the next patch.
>>
>> I also had to commonise tdesc_element_visitor and tdesc_element.
>>
>> This patch only differs from the V4 version in init_target_desc() and
>> the changing of constructors for regdef.
>
> Hi Alan,
>
> Just two small comment, but the patch LGTM with those answered or addressed.
>
>> diff --git a/gdb/gdbserver/tdesc.h b/gdb/gdbserver/tdesc.h
>> index 85139d948c..8eb88eedce 100644
>> --- a/gdb/gdbserver/tdesc.h
>> +++ b/gdb/gdbserver/tdesc.h
>> @@ -25,7 +25,10 @@
>> #include <vector>
>>
>> struct tdesc_feature
>> -{};
>> +{
>> + /* The registers associated with this feature. */
>> + std::vector<tdesc_reg_up> registers;
>> +};
>>
>> /* A target description. Inherit from tdesc_feature so that target_desc
>> can be used as tdesc_feature. */
>> diff --git a/gdb/regformats/regdef.h b/gdb/regformats/regdef.h
>> index 4775e863e9..7c80d45d48 100644
>> --- a/gdb/regformats/regdef.h
>> +++ b/gdb/regformats/regdef.h
>> @@ -21,15 +21,15 @@
>>
>> struct reg
>> {
>> - reg ()
>> + reg (int _offset)
>> : name (""),
>> - offset (0),
>> + offset (_offset),
>> size (0)
>> {}
>
> If this constructor is only used for padding entries, shouldn't name be
> NULL, as the documentation for the field states?
>
That creates two issues:
The reg:operator== segfaults in the strcmp due to the null.
Easily fixable, but a little ugly.
With that patched, the gdbserver unit tests will fail.
That is because the creation of target descriptions in the -generated.c files
in the build dir create the gaps using:
tdesc_create_reg (feature, “", 0, 0, NULL, 0, NULL);
Would fixing that cause more issues? Not sure.
Having “” rather than 0 does make sense when you format these to xml files.
We are explicitly setting to a blank string. Whereas null is more for uninitialised.
I was going to suggest fixing in a follow on patch, but the more I think about it,
The more I’m thinking “” is correct.
> Also, did you notice something failing if the padding entries don't have
> the offset field to the "current" offset at the time they are created?
> If we could leave them at 0, I think it would keep things simpler. I
> stopped for a few seconds, wondering why init_target_desc did:
>
> tdesc->reg_defs.resize (regnum, reg (offset));
>
> and not just:
>
> tdesc->reg_defs.resize (regnum);
Again, this creates unit test failures due to the same tdesc_create_reg above.
Here offset is a little more explicit, and setting to 0 says it’s at the start of the
description, which isn’t right.
Thanks again for the reviews.
Alan.
next prev parent reply other threads:[~2018-04-18 9:03 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-10 14:34 [PATCH v5 0/8] Remove gdbserver dependency on xml files Alan Hayward
2018-04-10 14:34 ` [PATCH v5 6/8] Create xml from target descriptions Alan Hayward
2018-04-18 2:43 ` Simon Marchi
2018-04-18 21:26 ` Alan Hayward
2018-04-10 14:34 ` [PATCH v5 2/8] Commonise tdesc_feature Alan Hayward
2018-04-10 14:34 ` [PATCH v5 4/8] Add tdesc osabi and architecture functions Alan Hayward
2018-04-18 2:10 ` Simon Marchi
2018-04-10 14:34 ` [PATCH v5 7/8] Remove xml file references from target descriptions Alan Hayward
2018-04-10 14:34 ` [PATCH v5 5/8] Add feature reference in .dat files Alan Hayward
2018-04-10 14:34 ` [PATCH v5 3/8] Commonise tdesc types Alan Hayward
2018-04-10 14:34 ` [PATCH v5 1/8] Commonise tdesc_reg Alan Hayward
2018-04-18 1:57 ` Simon Marchi
2018-04-18 9:03 ` Alan Hayward [this message]
2018-04-18 13:54 ` Simon Marchi
2018-04-10 14:34 ` [PATCH v5 8/8] Remove xml files from gdbserver Alan Hayward
2018-04-18 2:49 ` [PATCH v5 0/8] Remove gdbserver dependency on xml files 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=41D75C72-120B-4EEC-BAA5-D48232DD51ED@arm.com \
--to=alan.hayward@arm.com \
--cc=gdb-patches@sourceware.org \
--cc=nd@arm.com \
--cc=simark@simark.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).