This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: Regarding Range Table
- To: Sekaran Nanja <snanja@cup.hp.com>
- Subject: Re: Regarding Range Table
- From: Jim Blandy <jimb@cygnus.com>
- Date: 28 Jul 1999 15:22:55 -0500
- Cc: Rajiv Mirani <mirani@cup.hp.com>, Mike Vermeulen <mev@hpclhayb.cup.hp.com>, gdb@sourceware.cygnus.com
- References: <37990D39.B393D61B@cup.hp.com> <np908343yh.fsf@zwingli.cygnus.com><379CCBBD.6E3FC2F3@cup.hp.com> <npn1wi3m05.fsf@zwingli.cygnus.com><379D1B3A.32B9121B@cup.hp.com>
> Jim>It makes more sense to me to add your new info to the struct symbol
> Jim>itself, so that value_of_variable can check it and complain
> Jim>appropriately. It would be nice to do it in a way which doesn't use
> Jim>much space if we don't have this kind of information for the symbol.
>
> Jim>What do you think?
Sekaran> Yes. It makes sense to add this info. to struct symbol to
Sekaran> keep things clean but we lose the new info. for an alias
Sekaran> symbol containing multiple ranges (Ex: variable has the same
Sekaran> home in several distinct ranges.). I think it is better to
Sekaran> save these new info. in range_list struct. Please let me know
Sekaran> what do you think about this.
Oh, I see --- just as a given variable home is valid only in certain
code ranges, your critical assignment motion info applies only to
certain code ranges. And the ranges for a critical assignment motion
record will usually be some arbitrary subset of the variable's home's
ranges.
So a structure like this would be sufficient:
struct symbol {
... contains address class and symbol value ...
struct range_list *ranges;
...
};
struct range_list {
CORE_ADDR start, end;
unsigned int set_early : 1;
unsigned int set_late : 1;
unsigned int unknown : 1;
int comes_from_line;
int moved_to_line;
struct range_list *next;
};
Is that enough to accurately represent all the information you have?
Does it seem to be a straightforward representation, or is it obscure?
Is it possible for both set_early and set_late to be true for a given
range? It seems to me that set_late means that the variable is dead,
while set_early means that the variable is live, but not live in the
way one would expect from reading the source. Aren't set_early,
set_late, and unknown all mutually exclusive conditions? If that's
true, they should be represented with an enum, not as separate bits.
I think comes_from_line and moved_to_line should be CORE_ADDR's, not
line numbers. The mapping between source location and code is already
represented elsewhere; we shouldn't mix it in here if we don't have
to. We should convert them into line numbers when they are output.