Macro expansion: GCC 3.4.4

Macro expansion: GCC 3.4.4

[Nick Roberts]

Using gcc (GCC) 3.4.4 20050721 (Red Hat 3.4.4-2), enum doesn't work and I
see a work around is to use -fno-eliminate-unused-debug-types.

I also find that macro expansion doesn't work"

In myprog.c: #define NCR 4


cc -g3 -o myprog myprog.c myprint.o -lm


(gdb) b main
Breakpoint 1 at 0x80484b9: file myprog.c, line 52.
(gdb) run
Starting program: /home/nickrob/myprog

Breakpoint 1, main (argc=1, argv=0xfee4d1b4) at myprog.c:52
52        int i, n, m[10]={0,1,4,9,16,25,36,49,64,81};
(gdb) p NCR
No symbol "NCR" in current context.


Is there a work around for this too?

Thanks,

Nick

Prevent stack variable initialization to zero with -g

[Stuart Brooks]

Hi,

I recall reading somewhere (can't seem to find it now) that, when
compiling with -g, all stack variables are zeroed. Experience has also
shown this to be the case. However in optimized mode this can't be
relied upon - which is fine and as expected.

I was wondering if there is any way to prevent gcc from zeroing them in
"-g" mode as this tends to conceal uninitialized variables in debug
testing which then bite us in release. It would be great to be able to
force it to initialize them to some unusual byte value, but maybe that
is just wishful thinking. I have had a look through the man page but
nothing jumped out at me, maybe I missed something?

We are building on gcc 3.3.3 on Netbsd 2, and gcc 1.95.3 on Netbsd
1.6.2.

Thanks
 Stuart

Re: Prevent stack variable initialization to zero with -g

[Florian Weimer]

* Stuart Brooks:

> I recall reading somewhere (can't seem to find it now) that, when
> compiling with -g, all stack variables are zeroed.

This is not the case; compiling with debugging information does not
change the generated machine code.

Re: Macro expansion: GCC 3.4.4

[John Love-Jensen]

Hi Nick,

NCR is not a symbol.  It is part of a preprocessor directive.

Use:
int const NCR = 4; // internal linkage
...or...
extern int const NCR = 4; // external linkage

Then it is a symbol.  (This should work in C++98, I'm not sure about C99.)

HTH,
--Eljay

Re: Macro expansion: GCC 3.4.4

[Daniel Berlin]

On Wed, 2005-11-09 at 06:59 -0600, John Love-Jensen wrote:
> Hi Nick,
> 
> NCR is not a symbol.  It is part of a preprocessor directive.

True, but recent gcc + gdb have support for macro debugging info and
expansion.

So what he did should have worked given a new enough version of both.

Re: Macro expansion: GCC 3.4.4

[Nick Roberts]

John Love-Jensen writes:
 > Hi Nick,
 > 
 > NCR is not a symbol.  It is part of a preprocessor directive.

Yes, but if I do:

(gdb) inf source
Current source file is myprog.c
Compilation directory is /home/nickrob
Located in /home/nickrob/myprog.c
Contains 96 lines.
Source language is c.
Compiled with DWARF 2 debugging format.
Includes preprocessor macro info.
^^^^^^^^

It tells me that the executable should have information about that directive.

GDB is GNU gdb Red Hat Linux (6.1post-1.20040607.43rh) but I get the same
result with GDB from the CVS repository, which worked with an earlier GCC (3.2
something on Mandrake 9), so I'm pretty sure that the problem doesn't lie with
GDB.

Nick

Re: Macro expansion: GCC 3.4.4

[M Ranga Swami Reddy]

Hi,

The test case should be compiled with -g3 option. The '-g3' option 
include the macro definitions present in the program, in debugging 
information.

Regards,
Swami

--
Sankhya Technologies Private Limited
http://www.sankhya.com


On Thu, 10 Nov 2005, Nick Roberts wrote:

> John Love-Jensen writes:
>  > Hi Nick,
>  > 
>  > NCR is not a symbol.  It is part of a preprocessor directive.
> 
> Yes, but if I do:
> 
> (gdb) inf source
> Current source file is myprog.c
> Compilation directory is /home/nickrob
> Located in /home/nickrob/myprog.c
> Contains 96 lines.
> Source language is c.
> Compiled with DWARF 2 debugging format.
> Includes preprocessor macro info.
> ^^^^^^^^
> 
> It tells me that the executable should have information about that directive.
> 
> GDB is GNU gdb Red Hat Linux (6.1post-1.20040607.43rh) but I get the same
> result with GDB from the CVS repository, which worked with an earlier GCC (3.2
> something on Mandrake 9), so I'm pretty sure that the problem doesn't lie with
> GDB.
> 
> Nick
> 

Re: Macro expansion: GCC 3.4.4

[Daniel Berlin]

On Thu, 2005-11-10 at 11:11 +1300, Nick Roberts wrote:
> John Love-Jensen writes:
>  > Hi Nick,
>  > 
>  > NCR is not a symbol.  It is part of a preprocessor directive.
> 
> Yes, but if I do:
> 
> (gdb) inf source
> Current source file is myprog.c
> Compilation directory is /home/nickrob
> Located in /home/nickrob/myprog.c
> Contains 96 lines.
> Source language is c.
> Compiled with DWARF 2 debugging format.
> Includes preprocessor macro info.
> ^^^^^^^^
> 
> It tells me that the executable should have information about that directive.
> 
> GDB is GNU gdb Red Hat Linux (6.1post-1.20040607.43rh) but I get the same
> result with GDB from the CVS repository, which worked with an earlier GCC (3.2
> something on Mandrake 9), so I'm pretty sure that the problem doesn't lie with
> GDB.


If you run readelf -wm on the executable, does it display your macro
somewhere?

If so, then we've put it in the debug info, and that's all we can do :)

> 
> Nick

Re: Macro expansion: GCC 3.4.4

[Daniel Berlin]

On Thu, 2005-11-10 at 13:09 +0530, M Ranga Swami Reddy wrote:
> Hi,
> 
> The test case should be compiled with -g3 option. The '-g3' option 
> include the macro definitions present in the program, in debugging 
> information.

If he hadn't compiled with -g3, gdb wouldn't say it includes
preprocessor macro info.

Re: Macro expansion: GCC 3.4.4

[Nick Roberts]

Daniel Berlin writes:
 > > GDB is GNU gdb Red Hat Linux (6.1post-1.20040607.43rh) but I get the same
 > > result with GDB from the CVS repository, which worked with an earlier GCC
 > > (3.2 something on Mandrake 9), so I'm pretty sure that the problem
 > > doesn't lie with GDB.

 > If you run readelf -wm on the executable, does it display your macro
 > somewhere?

It has the line:

 DW_MACINFO_define - lineno : 6 macro : NCR 4

 > If so, then we've put it in the debug info, and that's all we can do :)

Should that guarantee GDB will find it?  Does GDB just use readelf or the
same libraries?

I presumed this would be a known problem, thats why I didn't mail it to
gcc-bugs.  Of course, I could be doing something stupid, but I'm not really
doing anything - just using Fedora Core 3.

Nick

Re: Macro expansion: GCC 3.4.4

[Daniel Berlin]

On Fri, 2005-11-11 at 08:12 +1300, Nick Roberts wrote:
> Daniel Berlin writes:
>  > > GDB is GNU gdb Red Hat Linux (6.1post-1.20040607.43rh) but I get the same
>  > > result with GDB from the CVS repository, which worked with an earlier GCC
>  > > (3.2 something on Mandrake 9), so I'm pretty sure that the problem
>  > > doesn't lie with GDB.
> 
>  > If you run readelf -wm on the executable, does it display your macro
>  > somewhere?
> 
> It has the line:
> 
>  DW_MACINFO_define - lineno : 6 macro : NCR 4

and in gdb, if you use "macro expand NCR", does it work?

> 
>  > If so, then we've put it in the debug info, and that's all we can do :)
> 
> Should that guarantee GDB will find it?  Does GDB just use readelf or the
> same libraries?

It doesn't, unfortunately, so it doesn't guarantee GDB is processing the
macro info right.

But it does mean we are putting it in the debug info.

It's also possible the file or line number is being set wrong, etc.
But you'd need to debug gdb to see it.

> 
> I presumed this would be a known problem, thats why I didn't mail it to
> gcc-bugs.  Of course, I could be doing something stupid, but I'm not really
> doing anything - just using Fedora Core 3.
> 
> Nick

Re: Macro expansion: GCC 3.4.4

[Nick Roberts]

 > and in gdb, if you use "macro expand NCR", does it work?

It just gives:

(gdb) macro expand NCR
expands to: NCR

but I think we're getting closer.  "info macro NCR" gives:

(gdb) info macro NCR
The symbol `NCR' has no definition as a C/C++ preprocessor macro
at /usr/include/stdlib.h:-1

with both GNU gdb Red Hat Linux (6.1post-1.20040607.43rh)
and GNU gdb 6.3.90-20051104-cvs

GDB is looking in the wrong place, but does GCC tell it where to look?

Nick