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

[Tom Tromey <tromey@redhat.com>]

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

Jan> I did not think such optimization is worth the work.  But I am
Jan> aware you and Google did various work on the memory footprint
Jan> reduction.  From my point of view 32-bit GDB without
Jan> --enable-64-bit-bfd either does not exist (anywhere in Fedora) or
Jan> it is some very special build.

Yeah.

Jan> The problem is LOC_CONST_BYTES needs special handling and current
Jan> accessor of SYMBOL_VALUE and its other union-accessors like
Jan> SYMBOL_VALUE_BYTES cannot be easily protected in any way without
Jan> either ({ forbidden GCC extensions }) or ->C++_accessor() so I am
Jan> reluctant to break existing code blindly expecting LOC_CONST
Jan> without checking it and using SYMBOL_VALUE.

If that code exists it has to be a crash waiting to happen.

Jan> Also I think if 40 vs. 44 minimal_symbol size is of any concern we
Jan> should do some real fixes such as lazy objfiles reading or lazy
Jan> minimal_symbol expansion.  partial_symbol memory cost seems to be
Jan> fixed by .gdb_index already, isn't it?

I guess so, but it isn't universally used (and really isn't that good
for all uses).  And as you've pointed out, idb does fine without needing
this.

Jan> Full symbol tables get expanded in some cases but that should also
Jan> be fixed in a real way (such as some <tab>-complation expands them
Jan> while it could not have to) instead of saving 4 out of 44 bytes.

The completion thing is an interesting idea.
It does seem pointless to expand symtabs in this case.
I wonder if there is a rationale.

Tom