Re: Designs for better debug info in GCC

["J.C. Pizarro" <jcpiza at gmail dot com>]

On Nov 26, 2007, "Alexandre Oliva" <aoliva@redhat.com> wrote:
> On Nov 26, 2007, "Richard Guenther" <richard.guenther@gmail.com> wrote:
> > On Nov 26, 2007 7:57 AM, Alexandre Oliva <aoliva@redhat.com> wrote:
> >> On Nov 24, 2007, "Richard Guenther" <richard.guenther@gmail.com> wrote:
> >>
> >> > No, hashing is fine, but doing walks over a hashtable when your algorithm
> >> > depends on ordering is not.
> >>
> >> Point.
> >>
> >> > I have patches to fix the instance of walking over all referenced
> >> > vars.  Which is in the case of UIDs using bitmaps and a walk over a
> >> > bitmap (which ensures walks in UID order).
> >>
> >> Why is such memory and CPU overhead better than avoiding the
> >> divergence of UIDs in the first place?
>
> > Actually my patches should be an overall memory savings.
>
> Err...  I don't see how using a bitmap in addition to a hashtable can
> save memory over using only a hashtable.  Or are you saying you do
> away with the hashtables?  I can see that this is possible and
> desirable.
>
> > But, as you (and me and others) look at bugs that happen because of
> > UID divergence, it is easier to use UIDs in a way that guarantees
> > that generated code does not change in such cases.
>
> Agreed, this property is desirable.  But I wouldn't say it is enough.
> Ensuring UIDs remain constant across compilations has helped
> tremendously in locating other compilation divergences, for comparing
> debug dumps becomes much easier.  So, even if we use algorithms that
> don't depend on UIDs remaining constant across compilations, I believe
> it is highly desirable that we keep them constant across compilations.
>
> > Otherwise what's the point in using UIDs?
>
> There are several different reasons for having UIDs, some of which
> could be having some unique identifier for an object, even in the
> presence of a moving garbage collector; being able to create
> fully-ordered sets of objects; being able to easily identify objects
> across a single compilation; being able to easily identify objects
> even across multiple compilations; and I'm sure it's possible to come
> up with other reasons that would justify the idea of UIDs on their
> own.

Hashtables? Bitmaps? Why not to use a database manager?

Maintaining UIDs only in memory isn't a good idea if many re-compilations
has to make.

I've a better idea to maintain the UIDs (unique identifiers of objects)
across compilations using the fastest database's manager "Tokyio Cabinet"
( http://tokyocabinet.sourceforge.net/ ) LGPLed instead of "Berkeley DB".

To use MD4 (128), MD5 (128) or SHA1 (160) as one-way hashing function of UIDs.

The implementor must to decide how to be the coding of input for the hashing
function of UID and how to store the complex object of UID in the DB.

The info to store each object, it's an example:

{ UID, compiled version of GCC, name of object, path of object, creation date,
  type of object, namespace that is using, number of parameters, options
  passed to GCC,  last access data for elimination from bigger cache, etc. }

Sincerely, J.C.Pizarro