From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Berlin To: Jim Blandy Cc: Daniel Berlin , gdb-patches@sources.redhat.com Subject: Re: macro-expanding expressions in GDB Date: Thu, 07 Jun 2001 09:01:00 -0000 Message-id: <87vgm8b7os.fsf@cgsoftware.com> References: <87ofsldrgr.fsf@dynamic-addr-83-177.resnet.rochester.edu> <15134.47162.825017.119342@kwikemart.cygnus.com> <87g0dc7u5w.fsf@cgsoftware.com> X-SW-Source: 2001-06/msg00128.html Jim Blandy writes: > Daniel Berlin 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 (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