Re: macro-expanding expressions in GDB

[Daniel Berlin <dan@cgsoftware.com>]

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

> Daniel Berlin <dan@cgsoftware.com> 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.

Right.

> 
> - They don't have addresses or types, so the fields of struct symbol
>   are mostly garbage.
> 
Right.

> - Struct symbol doesn't have anyplace really appropriate to store
>   an argument list.
Right again.

> 
> I would want them in a separate structure that can accurately
> represent their behavior.
I had them there, then i changed it.
I'll change it back.

> 
> 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.
Right. Well, yet, anyway.
There is an accepted proposal for discontiguous scopes, which may let
you do this, actually (even though that's not it's real intention).


The best we can do right now is take the PC you give us, find the
closest line, and tell you what macros were in force at that *line*.
And we can do this perfectly, actually.


> 
>> 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.

This isn't possible/genreally considered a bad idea.
We had this discussion on the gcc list a few weeks ago, i asked for
the very same thing.
Everyone told me this was a bad idea.
:)


-- 
"My neighbor has a circular driveway...  He can't get out.
"-Steven Wright