Re: macro-expanding expressions in GDB

[Daniel Berlin <dan at cgsoftware dot com>]

Jim Blandy <jimb@zwingli.cygnus.com> writes:

> Daniel Berlin <dan@cgsoftware.com> writes:
>> Speaking of real parsers, i've hooked up GCC's cpplib to GDB's c
>> expression parser if anyone is interested in the work.  I'll
>> eventually submit it once the hooks to do the necessary gdb lookups to
>> handle macros are done.  Neil said he'd try to have something
> 
> This is a feature to die for.  Fantastic.
> 
> I have two concerns about using cpplib:
> - I don't want GDB builds to require the GCC sources around.  This is
>   mostly bureacracy --- we'd need to have cpplib moved into its own
>   top-level directory, so we could share it with GCC.

I was going to bring this up right after gcc 3.0.  Everyone is running
around fixing high priority bugs, doing more documentation work, etc,
preparing for the June 15th release, so it would get ignored until
then.

> - I wonder how much of cpplib we actually need.  We don't need
>   #includes, #ifs, or CPP expression evaluation.  cpplib seems
>   heavyweight.  This is somewhat nitpicky.

Then again, IIRC, Stan Shebs and Apple were interested in using cpplib
to fake the dwarf2 macro info we get (IE parse the actual files to
produce the same type of info).

It's not as difficult as one would think to do this, actually, but
it's still a pain in the ass (especially since it requires all the
source files around).

> 
> Sorry, which Niel?

Neil Booth <neil@daikokuya.demon.co.uk> (or so BBDB tells me).

He's one of the two people who *really* understands and maintains
cpplib.

>   If I can find the bandwidth, I'd love to do the
> symbol table support for this.

I've actually already done it, I can post it if you like.

Macros live in the MACRO_NAMESPACE.
Each macro's name is it's symbol name.
The text of the macro is the symbol's value.

The hardest part was actually getting the macros into the right
blocks, as you would imagine.

The callback i'm referring to is the fact that we need cpplib to
provide a callback when it goes to determine if something is a macro
or not.  That way, we can look it up in gdb's symbol table instead.  Right
now, it looks it up in it's internal symbol table.  This will of
course, never find it.   The other ways around this (not using a
callback) are so hairy it's not even funny.  There was a discussion
about it on the gcc list.

> 
>> I also submitted patches to gcc to make it produce the dwarf2 macro
>> info necessary for us to let the user use macros from GDB that are
>> used in the source.
> 
> And we don't even need to wait for that.  We can add the macro info to
> the .s files manually, and test against those files.
Right.


-- 
"I can remember the first time I had to go to sleep.  Mom said,
"Steven, time to go to sleep."  I said, "But I don't know how."
She said, "It's real easy.  Just go down to the end of tired and
hang a left."  So I went down to the end of tired, and just out
of curiosity I hung a right.  My mother was there, and she said
"I thought I told you to go to sleep."
"-Steven Wright