From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stan Shebs To: Jim Blandy Cc: Daniel Berlin , gdb-patches@sources.redhat.com Subject: Re: macro-expanding expressions in GDB Date: Thu, 07 Jun 2001 11:16:00 -0000 Message-id: <3B1FC494.FD584945@apple.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/msg00140.html Jim Blandy wrote: > > 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. Amen. If I didn't have so many Apple-specific *&^%#$@! patches to deal with, I'd want to be having fun with this. > 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. Presumably it can be handled similarly to libiberty, with two copies, and on-demand resyncing. Since GDB only needs the subset functionality, it can probably be a little behind without causing any problems. > - 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. It's true that cppmacro.c is only about 10% of the cpplib sources, but in practice it seems like a lot of trouble to further partition cpplib. GDB doesn't use all of BFD either, but who wants to go to the trouble of partitioning it into a reading-only part? > Sorry, which Niel? That's Neil Booth. Stan