Re: Regarding Range Table

[Jim Blandy <jimb@cygnus.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.