Re: [patch] Support 64-bit constants/enums on 32-bit host [Re: [PATCH] Allow 64-bit enum values]

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Jan> The expansion is for partial_symbol -> symbol which may have some
Jan> sense as it saves almost 50% of space, both represent one DWARF
Jan> symbol.

I looked into this recently while thinking about lazy CU expansion.

The main difficulty is that you need a way to associate the psymbol with
the full symbol.  Right now there is no way at all to do this.  In DWARF
terms this means storing the DIE offset in the psymbol.

But, this is a problem for two reasons.  First, the bcache really helps
with the size of psymbols, but if you store the DIE offset in the
psymbol itself, it will defeat the purpose of the bcache.  Second, of
course, adding anything to psymbols makes them larger; and since most
psymbols are not in fact expanded, the overall effect may be a lose.

This latter consideration is why I am not yet persuaded that the change
is worth doing in isolation.

I think it could be done by storing the DIE offset in the psymbol lists,
instead of in the psymbol itself.  This could be a fairly localized
change (even optional, per-objfile) in psymtab.c.

Then, you could have two variants of struct symbol -- one that has a
pointer to its corresponding psymbol, and one that includes the psymbol.
This would mean updating all the accessors to check a bit in the symbol.

Due to the way that struct symbol is packed, I think this would only
save sizeof(general_symbol_info) - sizeof(void*) bytes (32 bytes per
symbol on x86-64).


This idea would make lazy CU expansion a bit faster, because you
wouldn't have to re-scan the DIEs to make the symbol table.

Then the idea would be to make symbols whose types and (for functions)
blocks are uninitialized, then change SYMBOL_TYPE et al to read and
interpret the necessary DIEs on demand.

I think this isn't extremely hard, but the tradeoffs are still not
entirely clear to me, and as you pointed out on irc, the result will
still probably be slower than idb -- IOW, we're doing something really
wrong, so why not start by finding that?

Tom