Work out how to properly represent aliases in the repo and in repo2obj.

[MaggieYingYi]

This is spin-off from PR #63.

Please see the details in #63 (review) and #63 (comment).

[paulhuggett]

This is probably fairly straightforward. In the repo, we need to be able to indicate which compilation members are aliases and the member of which they are an alias. That means that a compilation member will have to change from a simple symbol definition to a variant type something like:

struct compilation_member {
    string_address name;
    unsigned is_alias : 1;
    union {
        unsigned original;
        struct symbol {
            fragment
            linkage
            …
        };
    };
}

The original field is the index of the compilation_member in the owning compilation of the original symbol definition. The is_alias field for the target entry must be false.

Consumers (including pstore-dump, repo2obj, rld, and possibly others) will obviously need to understand this change. In the case of repo2obj, when an alias entry is encountered an additional symbol table entry must be created which points to the data for the original entry.

[paulhuggett]

The approach above may be rather wasteful since an alias reference is simply a name and an integer index (referring to the definition of which it’s an alias) where as the definition record contains a few additional fields to describe the thing being defined…

A more efficient approach (but more code) would be to have a variable-length array of aliases immediately following the variable-length array of definitions in the store. The overhead would then be an integer field to describe the number of aliases.

Something a bit like:

struct alias {
    string_address name;
    unsigned original;
};

struct definition {
    index::digest digest;
    extent<fragment> fext;
    string_address name;
    …
    linkage
    visibility
};

struct compilation {
    unsigned num_definitions;
    unsigned num_aliases;
    definition definitions[num_definitions];
    alias aliases[num_aliases];
};

[paulhuggett]

an alias reference is simply a name and an integer index

That isn’t quite true. According to the LLVM language specification (here), “Aliases may have an optional linkage type, an optional runtime preemption specifier, an optional visibility style, an optional DLL storage class and an optional tls model.” With most fields common to definitions, aliases, and IFuncs the original suggestion may be better.

[MaggieYingYi]

The weak_alias issue musl-prepo@issue8 is also caused by this issue.

[paulhuggett]

The weak_alias issue musl-prepo@issue8 is also caused by this issue.

How have you reached this conclusion? Following your link, I see mention of a C macro named weak_alias, but it’s not clear — at least not yet — how this macro and compiler support for LLVM IR aliases are related.

[MaggieYingYi]

The weak_alias issue musl-prepo@issue8 is also caused by this issue.

How have you reached this conclusion? Following your link, I see mention of a C macro named weak_alias, but it’s not clear — at least not yet — how this macro and compiler support for LLVM IR aliases are related.

A comment is given to demo the relationship between the macro and the IR aliases.