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

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Tue, 17 Apr 2012 16:32:54 +0200, Tom Tromey wrote:
> But the comment that you removed seems to indicate another possible
> approach -- just use LOC_CONST_BYTES for these enum values.
> 
> Would that not work for some reason?
> 
> I am thinking that presumably people who build a 32-bit gdb without
> --enable-64-bit-bfd are interested in the smallest memory footprint.
> Also presumably they are not likely to be debugging many 64 bit
> processes or perhaps even using enums with values requiring 64 bits;
> certainly those would be relatively rare cases.  So, if LOC_CONST_BYTES
> works, it would be an overall memory savings.
> 
> What do you think of this?

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

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

Also I think if 40 vs. 44 minimal_symbol size is of any concern we should do
some real fixes such as lazy objfiles reading or lazy minimal_symbol
expansion.  partial_symbol memory cost seems to be fixed by .gdb_index
already, isn't it?  Full symbol tables get expanded in some cases but that
should also be fixed in a real way (such as some <tab>-complation expands them
while it could not have to) instead of saving 4 out of 44 bytes.


Thanks,
Jan