I frequently debug---using ddd (or gdb)---code compiled from source that relies
upon macros (as in macros handled by cpp).  Is ddd/gdb lame to the extent that
there is no way to "enable" it so that it knows and works with macro
definitions?  I would be willing to recompile (if some gcc option is
first required).  As things are now, I consistently get "No symbol ...
in current context" whenever ... is a macro!  If gcc/ddd/gdb are unable to
do the job, then is there a gnu solution (providing a macro-aware debugging
environment) ?  What is it?

---

Clarification of Question by ignorant-ga on 14 Jul 2004 07:57 PDT

Well... ddd shows the source in a window where one may peruse the macro
definitions!  Whereas gcc does receive the output of cpp (there macros
have been expanded), ddd (and gdb) have full access to *every* macro
definition, as evidenced by their ability to list source!

Moreover, I am concerned *only* with the case where full source is
available.  Hence there are no information-theoretic nor conceptual
reasons preventing ddd (or gdb) from providing a macro aware debugging
environment.  

I do realize ddd/gdb are free, and one therefore should not complain;
so I hereby publicly appologize for alluding to their apparent
macro-challenged nature as lame...  And it could be the case (as
far as I know) that there *is* some way to coax the collection
cpp/gcc/ddd/gdb into giving far better macro support than what I am
currently experiencing ("No symbol ...in current context").

I was once told that "gcc -gdwarf-2 -g3 ..." together with coaxing
given to ddd would help, but I was never able to make anything
in that direction work.  Moreover, I have been told that even if I
could make progress in that direction,  the ## token-splicing
operator, the # stringification operator, and variable-arity macros
would not be handled properly.

I have also used -E to stop after preprocessing, and then proceeded
with the output as if it were my source...  But drawbacks include:

1) The syntactic sugar (macros) is gone.

2) The output of cpp is not pretty-printed (as done, for example,
   by emacs in C mode) and my decaying eyesight needs a crutch
   of that sort to make sense of source.

I do not know how to noninteractively pretty-print C, which would
help me with drawback 2 above, and while on this train of thought
I will also mention that there is no apparent way to have cpp
generate a newline in it's output (which in some situations is
decidedly inconvenient, though someome once told me to fix it by
rewriting cpp based on gnu M4, which I don't believe I have the
time or stomach to do).

So let me amend (broaden) the question... I will happly pay the
google answer fee for a nice (gpl) noninteractive pretty-print
program (which I can use to ameliorate point 2 above) and for
a bullet-proof method to generate newlines in macro expansions,
since I then could cobble together an acceptable code transformer.

---

Clarification of Question by ignorant-ga on 15 Jul 2004 11:32 PDT

I'm closing this because after poking around a bit:

Indent---"A GNU program for formatting C code"---should do my pretty printing,
and sed/awk squeezed infront of and after cpp can handle generation of newlines,
so I guess I'll make a code transformer to take source and expand out the macros
to produce a nicely formatted macro-free result to use as source for debugging.
I would much prefer a full featured macro-aware debugger, but oh well...

P.S. I compiled the latest release of ddd, and now "gcc -gdwarf-2 -g3 ..."
     *does* provide a much improved macro experience... 
     although "Stringification is not implemented yet."

Hello Ignorant-ga,

Hmm. My default answer would be -
  No - you cannot refer to macro names in gdb / ddd.

The simple reason for this is based on gcc's design which in simple terms is:
  cpp | compile | assemble | ld
where literally the output of cpp is the input to "compile" and the
output of "compile" is the input of "assemble" and the output of
"assemble" is the input to the linker (ld).

[well - perhaps not that simple, but it appears to work that way to
the user; note that gcc may use temporary files instead of pipes]

If you are patient, you can review either:
  man cpp
  info cpp
to see the various options such as:
  -E to stop after preprocessing
  -S to stop after compiling, but do not assemble
  -c to stop after generating the object file
and so on. 

You can then see from the output of:
  gcc -E a.c
that the compiler does not get any symbolic information for the
macros. That is why that data is not passed onto the debugger / why
you can't use macro names in the debugger.

Sorry. There may be other solutions [a for fee compiler / perhaps for
a different OS], but I am not aware of any GNU ones.

  --Maniac

I agree with maniac that directly it is not possible. However: if you
can use the C++ compiler g++ instead of gcc, AND if you are willing to
make changes to your code, there is a way. In C++, you can use (a)
const declarations in place of preprocessor constants without
parameters, and (b)inline functions in most places where C
preprocessor macros with parameters are needed. The following program
defines equivalent constants and parametric macros/functions using
these two mechanisms.

#include <stdio.h>

const int MaxSize = 64;
#define MAXSIZE 64

inline int max(int a, int b) { return (a > b) ? a : b; }
#define MAX(a, b) ( ((a) > (b)) ? (a) : (b))

int main() {
    printf("%d %d\n", MaxSize, MAXSIZE);
    printf("%d %d\n", max(10, 13), MAX(10, 13));
    return 0;
}

This compiles and runs correctly using g++ 3.2 with Cygwin under Win2k.

On the benefits of inline functions over parametric macros, see
http://www.parashift.com/c++-faq-lite/inline-functions.html

On why macros are evil in general, see
http://www.parashift.com/c++-faq-lite/misc-technical-issues.html#faq-38.5