[PATCH] Add tree and rtl accessor functions for debuggers

[Daniel Berlin]

On Thu, 10 May 2001, Ira Ruben wrote:

> At 3:10 PM -0700 5/10/01, Mark Mitchell wrote:
>
> >It would be even better to teach GDB to do this.
> >
> >It shouldn't be a very big project given that DWARF2 can conveniently
> >represent macro definitions and that cpplib makes expanding macros a
> >snap.
>
> I guess that's ok, if you are using DWARF2.  But we're not.
Sadly, I understand this is because of disk space usage.
STABS doesn't support macro info, AFAIK.
>
> On the other hand (thinking out loud), if DWARF2 is not a
> requirement, I suppose gdb could be hacked to allow a new path
> command of headers (much like dir), and have gdb expression
> processing handle undefined function id references to see if they are
> defined as macros in the specified headers, expand it, and use the
> result.
Why would you want to do this that way?
This is amazingly ugly.
Just enter them into the symbol table with a type of TYPE_CODE_MACRO, and
modify the
expression evaluation so that evaluation of a OP_FUNCALL on a symbol with
type TYPE_CODE_MACRO  involves expansion of the macro, and
returning the result.

This is pretty simple, and would require about 20 or 30 lines of code,
plus whatever it takes to interface to cpplib to have it give you back the
value, given a macro definition and argumens.

 If you want to try to hack around not having DWARF2 by making the
stabs  reader attempt to figure out what macros, and their values, are in
the headers it's proceessing, and inserrt them into the symbol
table, that's fine.

You'd be much better off just using DWARF2, but hey, whatever boats your
float.

But i'd certainly fight you tooth and nail if you tried to introduce
another thing that makes it harder to use more modern (in terms of
what most compilers produce these days.) debug formats like dwarf2 to the
fullest.

Consider, for example, that the whole partial symbol table idea in GDB is
because STABS  doesn't give you any kind of index into where various
symbols are  located, without searching through and basically doing at
least some processing on all of them.

Most other debug formats i've seen, including DWARF2 (though only SGI's
extensions give you all the tables necessary to completely lazy load
everything), provide tables of  names and types, so that this isn't
necessary.
However, because psymtabs are so embedded into gdb, we have to use them in
dwarf2, in a completely pointless waste of memory and time.  We actually
*can't* use the tables given to us, which is pretty silly.
I don't want to see the same kind of mistake made for macros.   If STABS
or whatever doesn't support representing them, in an easy to process way,
then fake it in the STABS reader, don't make GDB use another mechanism for
handling them, simply because STABS can't do it.

 > I am not sure how hard that would be to do and it does have
> the down side of not being able to handle conditionally defined
> macros.
>
> Ira
>