public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
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.


  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).