On 10/8/24 20:38, Sami Tolvanen wrote:
> The compiler may choose not to emit type information in DWARF for all
> aliases, but it's possible for each alias to be exported separately.
> To ensure we find type information for the aliases as well, read
> {section, address} tuples from the symbol table and match symbols also
> by address.
>
> Signed-off-by: Sami Tolvanen <samitolvanen@xxxxxxxxxx>
> Acked-by: Neal Gompa <neal@xxxxxxxxx>
> ---
> scripts/gendwarfksyms/gendwarfksyms.c | 2 +
> scripts/gendwarfksyms/gendwarfksyms.h | 13 +++
> scripts/gendwarfksyms/symbols.c | 148 ++++++++++++++++++++++++++
> 3 files changed, 163 insertions(+)
>
> diff --git a/scripts/gendwarfksyms/gendwarfksyms.c b/scripts/gendwarfksyms/gendwarfksyms.c
> index 1a9be8fa18c8..6fb12f9f6023 100644
> --- a/scripts/gendwarfksyms/gendwarfksyms.c
> +++ b/scripts/gendwarfksyms/gendwarfksyms.c
> @@ -103,6 +103,8 @@ int main(int argc, char **argv)
> error("open failed for '%s': %s", argv[n],
> strerror(errno));
>
> + symbol_read_symtab(fd);
> +
> dwfl = dwfl_begin(&callbacks);
> if (!dwfl)
> error("dwfl_begin failed for '%s': %s", argv[n],
> diff --git a/scripts/gendwarfksyms/gendwarfksyms.h b/scripts/gendwarfksyms/gendwarfksyms.h
> index 1a10d18f178e..a058647e2361 100644
> --- a/scripts/gendwarfksyms/gendwarfksyms.h
> +++ b/scripts/gendwarfksyms/gendwarfksyms.h
> @@ -66,14 +66,27 @@ extern int dump_dies;
> * symbols.c
> */
>
> +static inline unsigned int addr_hash(uintptr_t addr)
> +{
> + return hash_ptr((const void *)addr);
> +}
> +
> +struct symbol_addr {
> + uint32_t section;
> + Elf64_Addr address;
> +};
> +
> struct symbol {
> const char *name;
> + struct symbol_addr addr;
> + struct hlist_node addr_hash;
> struct hlist_node name_hash;
> };
>
> typedef void (*symbol_callback_t)(struct symbol *, void *arg);
>
> void symbol_read_exports(FILE *file);
> +void symbol_read_symtab(int fd);
> struct symbol *symbol_get(const char *name);
>
> /*
> diff --git a/scripts/gendwarfksyms/symbols.c b/scripts/gendwarfksyms/symbols.c
> index 4df685deb9e0..6cb99b8769ea 100644
> --- a/scripts/gendwarfksyms/symbols.c
> +++ b/scripts/gendwarfksyms/symbols.c
> @@ -6,8 +6,39 @@
> #include "gendwarfksyms.h"
>
> #define SYMBOL_HASH_BITS 15
> +
> +/* struct symbol_addr -> struct symbol */
> +static HASHTABLE_DEFINE(symbol_addrs, 1 << SYMBOL_HASH_BITS);
> +/* name -> struct symbol */
> static HASHTABLE_DEFINE(symbol_names, 1 << SYMBOL_HASH_BITS);
>
> +static inline unsigned int symbol_addr_hash(const struct symbol_addr *addr)
> +{
> + return hash_32(addr->section ^ addr_hash(addr->address));
> +}
> +
> +static unsigned int __for_each_addr(struct symbol *sym, symbol_callback_t func,
> + void *data)
> +{
> + struct hlist_node *tmp;
> + struct symbol *match = NULL;
> + unsigned int processed = 0;
> +
> + hash_for_each_possible_safe(symbol_addrs, match, tmp, addr_hash,
> + symbol_addr_hash(&sym->addr)) {
> + if (match == sym)
> + continue; /* Already processed */
> +
> + if (match->addr.section == sym->addr.section &&
> + match->addr.address == sym->addr.address) {
> + func(match, data);
> + ++processed;
> + }
> + }
> +
> + return processed;
> +}
> +
> static unsigned int for_each(const char *name, symbol_callback_t func,
> void *data)
> {
> @@ -22,9 +53,13 @@ static unsigned int for_each(const char *name, symbol_callback_t func,
> if (strcmp(match->name, name))
> continue;
>
> + /* Call func for the match, and all address matches */
> if (func)
> func(match, data);
>
> + if (match->addr.section != SHN_UNDEF)
> + return __for_each_addr(match, func, data) + 1;
> +
> return 1;
> }
This change means that symbol_get() doesn't return the first matching
symbol but the last one matched by an address.
For instance:
void foo(int a1) {}
void bar(int a1) __attribute__((alias("foo")));
The compiler produces the debug information only for foo() but
gendwarfksyms would instead report that it processed bar() when reading
this data, which is misleading. On the other hand, I don't immediately
see that it would result in an incorrect CRC or symtypes output, because
the symbols with the same address are effectively treated as one group,
so I'm not sure if this is important or not.
--
Thanks,
Petr
