Re: [commit] 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> BTW why we have minimal_symbol and expand it later when it has "the same"
Jan> size?  Just expanding the types would have the same effect.

We discussed on irc, Jan was confused :)

Jan> In all other configuration it has no memory footprint change.

Jan> -    /* The fact that this is a long not a LONGEST mainly limits the
Jan> -       range of a LOC_CONST.  Since LOC_CONST_BYTES exists, I'm not
Jan> -       sure that is a big deal.  */
Jan> -    long ivalue;
Jan> +    LONGEST ivalue;

Jan> Going to check it in, probably today, if there are any concerns about those
Jan> 4 added bytes.

I personally am not particularly concerned.

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?

Tom