From: "Guillermo E. Martinez" <guillermo.e.martinez@oracle.com>
To: Dodji Seketeli <dodji@seketeli.org>,
"Guillermo E. Martinez via Libabigail"
<libabigail@sourceware.org>
Subject: Re: [PATCH 2/5] ctf-front-end: Fix size and name for underlying types
Date: Tue, 29 Nov 2022 12:53:24 -0600 [thread overview]
Message-ID: <478886ff-7a15-9dd7-c20e-4af7b713637d@oracle.com> (raw)
In-Reply-To: <871qpmou3k.fsf@seketeli.org>
On 29/11/22 5:53, Dodji Seketeli wrote:
> Hello Guillermo,
>
> "Guillermo E. Martinez via Libabigail" <libabigail@sourceware.org> a
> écrit:
>
>> It fixed an incorrect representation in size and name for underlying
>> enum and struct types when it has a bitfield members:
>>
>> struct foo
>> {
>> unsigned bar : 2;
>> unsigned baz : 1;
>> };
>>
>> <type-decl name='' is-anonymous='yes' size-in-bits='2' id='type-id-1'/>
>>
>> So, `name' empty property, no showing the right enumerator's type and size
>> in bits:
>>
>> <type-decl name='unsigned char' size-in-bits='8' id='type-id-4'/>
>
> Hmmh, I think here, the name should be "unsigned int", because "unsigned
> bar" implicitly means 'unsigned int bar". And the size-in-bits should
> be set to 32.
>
Oh. Sorry, that's right.
> I have thus changed the introductory paragraphs of this commit log to
> the following:
>
> This patch fixes an incorrect representation in size and name of the
> underlying type of enums as well as underlying types of bitfield data
> members types.
>
> For instance, consider this struct.
>
> struct foo
> {
> unsigned bar : 2;
> unsigned baz : 1;
> };
>
> The data members bar and baz have an underlying type that is "unsigned
> int". Yet, the CTF front-end represents the underlying type of these
> data members as:
>
> <type-decl name='' is-anonymous='yes' size-in-bits='2' id='type-id-1'/>
>
> The name property is empty, and it should be "unsigned int".
>
> The size in bit is '2', but it should be the size of the underlying
> "unsigned int", in bits, which is 32.
>
> In other words, the underlying type of bar and baz should be:
>
> <type-decl name='unsigned int' size-in-bits='32' id='type-id-4'/>
>
> Note that today, libabigail doesn't represent the bitfield properties
> of the data member. Those bitfield properties are properties of the
> data member, not of their type. This is a known "Not Yet Implemented"
> feature request that has been filed upstream at
> https://sourceware.org/bugzilla/show_bug.cgi?id=27334.
>
> Similarly, the underlying type of enums is not properly represented by
> the CTF front-end.
>
> Fixed thus.
>
> It's a little bit more verbose, but hopefully, that should give a little
> bit more context for future code maintenance.
>
Totally agree. Thanks Dodji.
>>[...]
Kind regards,
guillermo
next prev parent reply other threads:[~2022-11-29 18:53 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-17 3:43 [PATCH 0/5] CTF front-end Bug Fixing and improvement Guillermo E. Martinez
2022-11-17 3:43 ` [PATCH 1/5] ctf-front-end: Set alignment-in-bits property to 0 Guillermo E. Martinez
2022-11-29 11:46 ` Dodji Seketeli
2022-11-17 3:43 ` [PATCH 2/5] ctf-front-end: Fix size and name for underlying types Guillermo E. Martinez
2022-11-29 11:53 ` Dodji Seketeli
2022-11-29 13:59 ` Dodji Seketeli
2022-11-29 18:32 ` [PATCHv2 2/5]ctf-front-end: " Guillermo E. Martinez
2022-11-30 9:14 ` Dodji Seketeli
2022-11-29 18:53 ` Guillermo E. Martinez [this message]
2022-11-17 3:43 ` [PATCH 3/5] ctf-front-end: Strip qualification from a qualified array type Guillermo E. Martinez
2022-11-30 9:33 ` Dodji Seketeli
2022-12-02 3:48 ` Guillermo E. Martinez
2022-11-17 3:43 ` [PATCH 4/5] ctf-front-end: Fix representation for multidimensional " Guillermo E. Martinez
2022-11-30 9:43 ` Dodji Seketeli
2022-11-17 3:43 ` [PATCH 5/5] ctf-front-end: Fix array size representation Guillermo E. Martinez
2022-11-30 9:58 ` Dodji Seketeli
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=478886ff-7a15-9dd7-c20e-4af7b713637d@oracle.com \
--to=guillermo.e.martinez@oracle.com \
--cc=dodji@seketeli.org \
--cc=libabigail@sourceware.org \
/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).