Re: Regarding Range Table

[Sekaran Nanja <snanja@cup.hp.com>]

Jim,
>>Oh --- that's too bad.  Line numbers aren't very precise; what if one
>>source file #includes another file?  Then the line number isn't
>>sufficient to actually identify the source location.  (I agree that
>>it's poor coding practice to #include a file into the midst of a
>>function, but it does happen.  Perhaps even in certain programs with
>>which we are all familiar.)
Yes. I agree. Please note that HP debug info. doesn't have the source file info.
for this info. and hence it assumes the current active file based on PC.  With the
existing  debug info., we can't  generate correct early set/late set warnings for
functions containing include files.

>>Reading them is a bit more troublesome, because this is something that
>>takes a enough long time for the user to complain about.  Also, it's
>>not clear that you have the line number table available when you are
>>reading your critical assignment motion info from the file.
I am also concerned about this.

>>So I think it's okay to leave them as line numbers for now, if you
>>prefer that.
Yes. I am planning to keep these as line numbers for now.


Thanks,
Sekaran.

Jim Blandy wrote:

> > >>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.
> > I think either CODE_ADDR or line number  is fine for this information. Since
> > HP debug info. format  saves this info. as line number,  it is preferable to
> > save this info. as line number  so that additional processing is not required
> > for both saving as well as displaying.
>
> Oh --- that's too bad.  Line numbers aren't very precise; what if one
> source file #includes another file?  Then the line number isn't
> sufficient to actually identify the source location.  (I agree that
> it's poor coding practice to #include a file into the midst of a
> function, but it does happen.  Perhaps even in certain programs with
> which we are all familiar.)
>
> If you've got a CORE_ADDR, on the other hand, we've got functions
> which will correctly find the right source file and line number, no
> matter what you've done with CPP.
>
> It's true that CORE_ADDRs must be converted to line numbers again on
> output, but that isn't critical to overall performance.  We can find
> them faster than the user can read them.
>
> Reading them is a bit more troublesome, because this is something that
> takes a enough long time for the user to complain about.  Also, it's
> not clear that you have the line number table available when you are
> reading your critical assignment motion info from the file.
>
> So I think it's okay to leave them as line numbers for now, if you
> prefer that.