From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Blandy To: Daniel Berlin Cc: gdb-patches@sources.redhat.com Subject: Re: macro-expanding expressions in GDB Date: Thu, 07 Jun 2001 11:52:00 -0000 Message-id: References: <87ofsldrgr.fsf@dynamic-addr-83-177.resnet.rochester.edu> <15134.47162.825017.119342@kwikemart.cygnus.com> <87g0dc7u5w.fsf@cgsoftware.com> <87vgm8b7os.fsf@cgsoftware.com> X-SW-Source: 2001-06/msg00147.html Daniel Berlin writes: > 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. Yeah. I guess I don't see the point in trying to fit them into the existing symbol table structure: - Macros aren't scoped in a block-structured fashion; they have ranges of lines over which they're in force. So the block tree is a total misfit for them. - They don't have addresses or types, so the fields of struct symbol are mostly garbage. - Struct symbol doesn't have anyplace really appropriate to store an argument list. I would want them in a separate structure that can accurately represent their behavior. Ideally, given an object code location, I want to be able to find the definitions that were in force when that object code was emitted. Unfortunately, we can't do this perfectly; if a file is #included more than once, perhaps with different #definitions in force each time, that control #if directives that establish different definitions for other macros, no debugging format (including Dwarf 2) provides enough information for us to tell which #inclusion corresponds to which code address. Dwarf 2's macro information does it right, but its text address <-> source location mapping doesn't. > 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. Yeah, to be useful to GDB, cpplib's expansion code needs to be decoupled from the rest of the CPP stuff --- and that includes the code for #define, which establishes the definitions in the first place.