Project

General

Profile

Actions

Feature #13696

open

ctf_member_info() should support C11 anonymous SOUs

Added by Jason King over 2 years ago. Updated over 2 years ago.

Status:
New
Priority:
Normal
Assignee:
Category:
lib - userland libraries
Start date:
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:
External Bug:

Description

C11 introduced the concept of anonymous struct unions. A common (pre-C11) idiom in C was something like:

struct foo {
    union bar {
        int b_ival;
        char *b_str;
        float b_float;
    } f_u;
    void *f_ptr;
};
#define f_ival f_u.b_ival
#define f_str f_u.b_str
#define f_float f_u.b_float

With C11, instead, one can merely do:

struct foo {
    union {
       int f_ival;
       char *f_str;
       float f_float;
    };
    void *f_ptr;
}; 

and expressions such as struct foo *f; f->f_str; will work -- the compiler enforces that there must be no ambiguity in the field names.

GNU has also allowed this behavior prior to C11.

Currently, the CTF tools will generate a union type with a 0-byte name. For things such as MDB and DTrace, it would be useful for them to be able to support this notation (since there's no other way to deference such fields. This way any software utilizing it (I've encountered at least some things in the wild) would allow us to use MDB and DTrace with them w/o this becoming a problem.

It seems like the most straightforward thing would be for ctf_member_info() to mimic the C11 behavior on lookup -- if a zero-byte struct or union name is found, recurse into it to look for the member name. Note that it's possible to have multiple anonymous SOUs (struct or unions) in the same enclosing SOU (as long as the 'no ambiguity rule still applies'), so one cannot merely get at the data by calling ctf_member_info() with a zero-byte member name (since there may be more than one).

From inspection, it appears Dtrace and MDB both uses ctf_member_info() to get things like types and offsets for SOU members, so adding the support here should (hopefully) allow them to support it as well without too much additional work.

Actions #1

Updated by Robert Mustacchi over 2 years ago

If we end up changing ctf_member_info() here, then we need to probably think carefully about ctf_member_iter() as well. Changing the latter will have a major impact on how diffing, merging, and uniquification work. If just changing ctf_member_info(), we may want to consider adding a flag to constrain that descent, especially if there is any nesting in this.

Actions

Also available in: Atom PDF