Can I compile C/C++ Debug version partially?

[Davy]

Hi all,

I use VC and gcc/gdb to compile and debug C/C++ files. But I found some
of the debug version of the compiled files are too large to be run in a
small RAM. Can I compile C/C++ Debug partially?

Something like:
fileA.c fileB.c
And I can compile fileA.c with debug info and compile fileB.c without
debug info?

Any suggestions will be appreciated!
Best regards,
Davy

 

[Ulrich Eckhardt]

I use VC and gcc/gdb to compile and debug C/C++ files. But I found some
of the debug version of the compiled files are too large to be run in a
small RAM. Can I compile C/C++ Debug partially?

I know of two possible ways:
1. Separate the debug-information from the executable. Some debuggers/debug
formats support this, IIRC, just see what your compiler/debugger/linker
supports and see if that helps.
2. Only compile parts of a program with debug-info turned on. This might
work pretty well with GCC, but VC links with different runtime libs for
debug and release mode, so you might have to fall back to some tricks
there to get it running.

Else, debug modules in unittests instead of the whole program, but that's
not always an option.

Uli

 

[Mark McIntyre]

Hi all,

I use VC and gcc/gdb to compile and debug C/C++ files. But I found some
of the debug version of the compiled files are too large to be run in a
small RAM. Can I compile C/C++ Debug partially?

This isn't a C or C++ language question. You need to read the
documentation for your compilers, and ask in compiler-specific
newsgroups.

 

[Malcolm]

I use VC and gcc/gdb to compile and debug C/C++ files. But I found some
of the debug version of the compiled files are too large to be run in a
small RAM. Can I compile C/C++ Debug partially?

Something like:
fileA.c fileB.c
And I can compile fileA.c with debug info and compile fileB.c without
debug info?

Any suggestions will be appreciated!

Probably not. The awkward workaround is probably to compile fileB.c as a
non-debug library and then link. However I don't know the details of gcc
well enough to quote.

As a hint, don't use debuggers. Use diagnostic printf()'s to work out what
the program is doing. I invariably find that debuggers are far more trouble
than they are worth with the exception of the tool to give a stack trace on
a crash. (However many regs will disgree with me on this).

 

[jacob navia]

Hi all,

I use VC and gcc/gdb to compile and debug C/C++ files. But I found some
of the debug version of the compiled files are too large to be run in a
small RAM. Can I compile C/C++ Debug partially?

Something like:
fileA.c fileB.c
And I can compile fileA.c with debug info and compile fileB.c without
debug info?

Any suggestions will be appreciated!
Best regards,
Davy

You are probably not aware that debug information
will NOT be loaded into RAM unless a debugger is
present.

 

[Simon Biber]

Probably not. The awkward workaround is probably to compile fileB.c as a
non-debug library and then link. However I don't know the details of gcc
well enough to quote.

As a hint, don't use debuggers. Use diagnostic printf()'s to work out what
the program is doing. I invariably find that debuggers are far more trouble
than they are worth with the exception of the tool to give a stack trace on
a crash. (However many regs will disgree with me on this).

No, I agree with you totally. The only time I ever fire up a debugger is
to work out where in some large program it is crashing.

I know some people love "break" and "watch" points, but I'd prefer to
look through a trace from my own printf calls. I wrote the program -- I
should understand what all the code means, I just have to find where I
made a mistake.

 

[Simon Biber]

You are probably not aware that debug information
will NOT be loaded into RAM unless a debugger is
present.

That's quite a strong statement! Are you sure that it's true of all C
implementations on all platforms? Or just your own lcc-win32?

 

[Keith Thompson]

That's quite a strong statement! Are you sure that it's true of all C
implementations on all platforms? Or just your own lcc-win32?

The OP specified a particular environment (VC and gcc/gdb); I'm
guessing jacob's answer was appropriate for that environment.

But I can't be sure, which is why such information is more appropriate
to a system-specific newsgroup where it can be checked.

 

[jacob navia]

That's quite a strong statement! Are you sure that it's true of all C
implementations on all platforms? Or just your own lcc-win32?

For the Visual C compiler of Microsoft the debug info is not even
in the executable but in the program database (.pdb files). So it
would be VERY surprising that it would be loaded into memory.

Normally under windows, the debug info is described in the debug
section of the data directory of the executable, and not in a section
that should be loaded by the program loader.

Most OSses will not map the debug info if no debugger is present.

Another possibility is that debug executables without any optimizations
are bigger than optimized programs, and in that case it would make
a small difference.

Files with or without debug info can be mixed freely in most
implementations that I know of, so the question of the memory
used by a program makes even less sense. If you just want to debug
module X you can eliminate all debug info from all other modules
and only compile with debug info for module X. The linker should
accept that anyway, and most debuggers will work in such a setting.

jacob