Exporting debugging symbols in a static .lib

[James Kanze]

Not sure if this is the right forum, but I can't find one which
is more appropriate.

What is the usual procedure for exporting debugging information
when delivering a static library (a .lib file)? The only
solution I've found to date is to copy all of the .pdb files for
the object files into the directory in which I deliver the .lib,
but this seems to defeat part of the purpose of using a library.
Is there any way of putting them into the .lib itself, or of
building a single .pdb for the library?

--
James Kanze

[Alex Blekhman]

Post by James Kanze
What is the usual procedure for exporting debugging
information when delivering a static library (a .lib
file)?

It is no different from .EXE or .DLL file. You supply the
resulting .PDB file along with the project output.

Post by James Kanze
The only solution I've found to date is to copy all of the
.pdb files for the object files into the directory in
which I deliver the .lib, but this seems to defeat part of
the purpose of using a library. Is there any way of
putting them into the .lib itself, or of building a single
.pdb for the library?

What you describe is strange. Usually you have one debug
info (program database) file name per project. It is defined
in project properties: C/C++ -> Output Files -> Program
Database File Name. Alternatively, you can use /Fd command
line switch with desired name.

If you don't specify /Fd option (either via project settings
or manually), then the .PDB file name defaults to VCx0.pdb.,
where x is the major version of Visual C++ in use. You
should recheck your build configuration.

HTH
Alex

[legalize+ (Richard)]

[Please do not mail me a copy of your followup]

Post by Alex Blekhman
If you don't specify /Fd option (either via project settings
or manually), then the .PDB file name defaults to VCx0.pdb.,
where x is the major version of Visual C++ in use. You
should recheck your build configuration.

I always thought that was a stupid default. It should default to
$(ProjectName).pdb.

[James Kanze]

Post by Alex Blekhman

Post by James Kanze
What is the usual procedure for exporting debugging
information when delivering a static library (a .lib
file)?

It is no different from .EXE or .DLL file. You supply the
resulting .PDB file along with the project output.

Which causes what commands to be generated? I'm building from
the command line.

Post by Alex Blekhman

Post by James Kanze
The only solution I've found to date is to copy all of the
.pdb files for the object files into the directory in which
I deliver the .lib, but this seems to defeat part of the
purpose of using a library. Is there any way of putting them
into the .lib itself, or of building a single .pdb for the
library?

What you describe is strange. Usually you have one debug info
(program database) file name per project. It is defined in
project properties: C/C++ -> Output Files -> Program Database
File Name. Alternatively, you can use /Fd command line switch
with desired name.

Aha (perhaps)! Does this mean that if I compile the different
objects with the same program database file, they'll merge,
rather than the last one overwriting the previous one?

I'm currently specifying /Fd using the object file name, with
.obj replaced by .pdb. I'll try it using the library name, but
it will require significant work (since the make function which
compiles the code doesn't know the library name).

Post by Alex Blekhman
If you don't specify /Fd option (either via project settings
or manually), then the .PDB file name defaults to VCx0.pdb.,
where x is the major version of Visual C++ in use.

That may be a good solution for me; I can later rename or copy
the file when building the library.

Post by Alex Blekhman
You should recheck your build configuration.

I could post my makefiles, but I doubt it would help much; I'm
using some fairly elaborate GNU makefiles for portability
reasons. (The makefiles, along with the sources, reside on a
shared drive, with the makefile configuring itself according the
the hostname and various environment variables.)

--
James Kanze

[Alex Blekhman]

Post by James Kanze

Post by Alex Blekhman
It is no different from .EXE or .DLL file. You supply the
resulting .PDB file along with the project output.

Which causes what commands to be generated? I'm building from
the command line.

For .EXE or .DLL file you run linker tool with /PDB command, which
generates resulting .PDB file. Also, linker embeds reference to
this .PDB file into the executable.

However, static library is built without linker. So, we have /Zi
(or /ZI) and /Fd compiler options to generate .PDB file. I have
never tested it personally, but it seems that compiler merges
debug information if the same .PDB filename is specified for
several source files.

Post by James Kanze
Does this mean that if I compile the different objects with the
same program database file, they'll merge, rather than the last
one overwriting the previous one?

Yes, it seems to be the case. I have static library project with
default .PDB filename ("VC90.pdb") for all source files.
Nonetheless, during debug session the information is available for
every symbol, no matter from which source file it came from.

Post by James Kanze

Post by Alex Blekhman
If you don't specify /Fd option (either via project settings or
manually), then the .PDB file name defaults to VCx0.pdb., where
x is the major version of Visual C++ in use.

That may be a good solution for me; I can later rename or copy
the file when building the library.

I am afraid this setup won’t work smoothly. The problem is that
compiler embeds full path of the .PDB file into .OBJ file. So, if
you rename original .PDB file, then you'll get into troubles
during debug session.

I think the best solution in your case is to specify /Z7 compiler
option. It will cause the compiler to generate debug info directly
into .OBJ files leaving out .PDB hustle altogether.

HTH
Alex

[James Kanze]

Post by Alex Blekhman

Post by James Kanze

Post by Alex Blekhman
It is no different from .EXE or .DLL file. You supply the
resulting .PDB file along with the project output.

Which causes what commands to be generated? I'm building
from the command line.

For .EXE or .DLL file you run linker tool with /PDB command,
which generates resulting .PDB file. Also, linker embeds
reference to this .PDB file into the executable.
However, static library is built without linker. So, we have
/Zi (or /ZI) and /Fd compiler options to generate .PDB file. I
have never tested it personally, but it seems that compiler
merges debug information if the same .PDB filename is
specified for several source files.

Post by James Kanze
Does this mean that if I compile the different objects with
the same program database file, they'll merge, rather than
the last one overwriting the previous one?

Yes, it seems to be the case. I have static library project
with default .PDB filename ("VC90.pdb") for all source files.
Nonetheless, during debug session the information is available
for every symbol, no matter from which source file it came
from.

A little bit of experimentation here seems to show the same
thing.

Post by Alex Blekhman

Post by James Kanze

Post by Alex Blekhman
If you don't specify /Fd option (either via project
settings or manually), then the .PDB file name defaults to
VCx0.pdb., where x is the major version of Visual C++ in
use.

That may be a good solution for me; I can later rename or
copy the file when building the library.

I am afraid this setup won’t work smoothly. The problem is
that compiler embeds full path of the .PDB file into .OBJ
file. So, if you rename original .PDB file, then you'll get
into troubles during debug session.

Ouch. That means that even copying the debug information for
each individual file won't work.

Post by Alex Blekhman
I think the best solution in your case is to specify /Z7
compiler option. It will cause the compiler to generate debug
info directly into .OBJ files leaving out .PDB hustle
altogether.

Yes. But is the debug information as complete? (And if so, why
doesn't Microsoft use it as the default, or even exclusively?)

I'll give it a try, anyway.

--
James Kanze

[Alex Blekhman]

Post by James Kanze
But is the debug information as complete?

Yes, it is the same debug information that goes into .PDB files.

MSDN:
<quote>
/Z7
Produces an .obj file containing full symbolic debugging
information for use with the debugger. The symbolic debugging
information includes the names and types of variables, as well as
functions and line numbers. No .pdb file is produced.

For distributors of third-party libraries, there is an advantage
to not having a .pdb file.
</quote>

Post by James Kanze
And if so, why doesn't Microsoft use it as the default, or even
exclusively?

Good question. Frankly, I ca only guess. With full debug
information the size of a file may become enormous. Also, you can
build in release mode and still produce .PDB file without
affecting lean and mean executable image.

Alex

[James Kanze]

[...]

Post by Alex Blekhman

And if so, why doesn't Microsoft use it [putting all debug
information in the object files] as the default, or even
exclusively?

Good question. Frankly, I ca only guess. With full debug
information the size of a file may become enormous. Also, you
can build in release mode and still produce .PDB file without
affecting lean and mean executable image.

Ah yes. So you can deliver without debug information, but still
have it for your own use.

Anyhow, thank's for the help. I'll go with the debug
information in my object files for now; file size of the
resulting .lib isn't really an issue for the moment, and I
actually want the clients to have access to the debug
information.

--
James Kanze