Board index » off-topic » Re: Any easy way or tool to know whether there is any debug info?

Re: Any easy way or tool to know whether there is any debug info?


2004-10-23 04:04:39 AM
off-topic10
Ed Mulroy [TeamB] wrote:
Quote
>Really? I think Win32 program also include debug
>info in the executable self, because the debug
>version is much bigger than the release version.

The release version is larger than the debug version because the C++
inline functions are expanded inline in the release version but not in
the debug version. The debug info is included in the companion *.tds
file, not in the *.exe file.
I think he said it was the other way round, release smaller than
debug.
That would make sense as debug versions could have more run-time
checking for debugging purposes (stack overflow, asserts, etc) that
would be removed to speed up the release version. Similarly, the
release version might have further code optimizations as
theoretically, a programmer no longer needs to be able to make sense
of it.
 
 

Re:Re: Any easy way or tool to know whether there is any debug info?

Before I release any program to the public, I'd like
to assure there is no any debug information in the
program.
Is there any easy way or any tool to check whether
there is any debug information in an exe or dll?
The debug information I care is Delphi's and TD32's
debug information.
I want to know this because maybe I forgot disable
debug switch, so if the program includes any debug
information, it will leak my work. :-)
For exe, I can use TD32 to see whether exists the
debug information manually (it's so dull work), but
for dll, no simple way.
 

Re:Re: Any easy way or tool to know whether there is any debug info?

Koms Bomb wrote:
Quote
Before I release any program to the public, I'd like
to assure there is no any debug information in the
program.
I don't recall that there is any debug info in a 32bit tasm (or C)
program. AFAIK these days it is all in *.tds files.
In the 16bit days there was, and tdstrip.exe would remove it.
Quote
Is there any easy way or any tool to check whether
there is any debug information in an exe or dll?
The debug information I care is Delphi's and TD32's
debug information.
Are you concerned about something like a C style assert() that is
supposed to compile differently?
Quote
I want to know this because maybe I forgot disable
debug switch, so if the program includes any debug
information, it will leak my work. :-)
Don't you use MAKE files?
# MAKE -r -DSHIP -fra7_lib
binpath=e:\cpp\bcc55\bin
!if $d(SHIP)
TASM = binpath\TASM /MX /ZN /z /m5 /p
TLINK = binpath\ilink32 /ap/x/c/C/Gn/w/L$(LIBPATH)
# Add your no-debug Delphi codes here
!else
TASM = binpath\TASM /MX /ZI /z /m5 /p
TLINK = binpath\ilink32 /ap/v/c/C/Gn/w/L$(LIBPATH) /s
#CC = binpath\bcc32 -6 -a1 -C -c -d -g50 -K -O2 -Oi -OS -Ov -Q -VI-
-tWC -vi -x- -I$(INCLUDEPATH) -L$(LIBPATH) -P- -M -v -DDEBUG
# Add your debugging Delphi codes here
!endif
## Then the rules to do a full make including the dlls
What I do, is have a batch file that deletes all of the obj then
invokes the make to rebuild everything. If the make command includes
-DSHIP, then no debug info is generated.
Quote
For exe, I can use TD32 to see whether exists the
debug information manually (it's so dull work), but
for dll, no simple way.
What debug information do you find that way?
 

{smallsort}

Re:Re: Any easy way or tool to know whether there is any debug info?

Quote
I don't recall that there is any debug info in a 32bit tasm (or C)
program. AFAIK these days it is all in *.tds files.
In the 16bit days there was, and tdstrip.exe would remove it.
Really? I think Win32 program also include debug info in the
executable self, because the debug version is much bigger
than the release version.
Quote
Don't you use MAKE files?
Yes, I use make file, and I defined a 'debug' macro in it.
But what I'm afraid is if I forget remove the 'debug' macro,
it will leak my source.
Quote
What debug information do you find that way?
TD32 debug info, of course.
Now I think I should remove the object files before I
make the release version like you did (But it's not very easy
because the object files come from several different path),
and then add some warning message if 'debug' macro is defined.
 

Re:Re: Any easy way or tool to know whether there is any debug info?

Quote
Really? I think Win32 program also include debug
info in the executable self, because the debug
version is much bigger than the release version.
The release version is larger than the debug version because the C++
inline functions are expanded inline in the release version but not in
the debug version. The debug info is included in the companion *.tds
file, not in the *.exe file.
. Ed
Quote
Koms Bomb wrote in message
news: XXXX@XXXXX.COM ...
 

Re:Re: Any easy way or tool to know whether there is any debug info?

Quote
Is there any easy way or any tool to check whether
there is any debug information in an exe or dll?
Look for section with name '.debug' in header of file.
 

Re:Re: Any easy way or tool to know whether there is any debug info?

Quote
Look for section with name '.debug' in header of file.
Oh, yeah. I find .debug section in a exe which generated
by TASM32 and Tlink32. I'll write a tool to detect this
when I have time.
How about the delphi program?
Maybe I'll ask in Delphi group.
But seems there is no any useful(eg, source code) in
Delphi debug version program, because the debug version is
only a little bigger than the release one.
 

Re:Re: Any easy way or tool to know whether there is any debug info?

Hi Koms,
TDStrp32 removes completely symbol and debug info from an EXE created with
TASM. I don't made DLL but I think TDStrp32 makes fine work in DLL too.
In Delphi the simplest way is swith off all debug options (options/compiler)
and rebuild the entire project.
"Koms Bomb" < XXXX@XXXXX.COM >schrieb im Newsbeitrag
Quote
Before I release any program to the public, I'd like
to assure there is no any debug information in the
program.
Is there any easy way or any tool to check whether
there is any debug information in an exe or dll?
The debug information I care is Delphi's and TD32's
debug information.
I want to know this because maybe I forgot disable
debug switch, so if the program includes any debug
information, it will leak my work. :-)
For exe, I can use TD32 to see whether exists the
debug information manually (it's so dull work), but
for dll, no simple way.


--
Koms Bomb



 

Re:Re: Any easy way or tool to know whether there is any debug info?

That has not been my experience. BCB C++ programs have been smaller
if built in debug mode than in release.
. Ed
Quote
Bob Gonder wrote in message
news: XXXX@XXXXX.COM ...
 

Re:Re: Any easy way or tool to know whether there is any debug info?

Quote
That has not been my experience. BCB C++ programs have been smaller
if built in debug mode than in release.
Well... both cases can apply.
Filesize is increased in release build due to:
-Any kind of speed optimization, including:
Loop unrolling, making code fit parallel execution units and
pipelining, inlined functions, expanding code paths, converting
complex instructions to simple ones, branching mapped to tables,
alignment padding
Filesize is increased in debug build due to:
-missing size optimization
-missing re-use of already calculated or loaded values
-asserts and other constraint checks are compiled into the code
-adding debug information
Sometimes, it is hard to determine wether optimizations increase or
decrease size: Optimized code usually has many loads, stores and
calculations stripped, but the amount of data reduced is often less
than the one added due to inlining and similar optimizations.
And a jump table may be shorter or larger than the same stuff done by
branching by a chain of conditional jumps.
Debug builds are usually way larger if debug info and assertions are
used, but without them the difference is far less - then, using
"optimize for size" or "optimize for speed" will make the release
build larger or smaller than the debug one...
 

Re:Re: Any easy way or tool to know whether there is any debug info?

Mostly agreed except for these:
Quote
-missing re-use of already calculated or loaded values
Some optimizations are there in all modes. Re-use of already
calculated or loaded values is one of them.
Quote
Debug builds are usually way larger if debug info
and assertions are used, but without them the
difference is far less - then, using "optimize for
size" or "optimize for speed" will make the release
build larger or smaller than the debug one...
There is no debug information in the executable. Debug information is
located in the companion *.tds file.
. Ed
Quote
TS wrote in message
news: XXXX@XXXXX.COM ...

>That has not been my experience. BCB C++ programs
>have been smaller if built in debug mode than in release.

Well... both cases can apply.

Filesize is increased in release build due to:
-Any kind of speed optimization, including:
Loop unrolling, making code fit parallel execution units and
pipelining, inlined functions, expanding code paths, converting
complex instructions to simple ones, branching mapped to tables,
alignment padding

Filesize is increased in debug build due to:
-missing size optimization
-missing re-use of already calculated or loaded values
-asserts and other constraint checks are compiled into the code
-adding debug information

Sometimes, it is hard to determine wether optimizations increase or
decrease size: Optimized code usually has many loads, stores and
calculations stripped, but the amount of data reduced is often less
than the one added due to inlining and similar optimizations.
And a jump table may be shorter or larger than the same stuff done
by
branching by a chain of conditional jumps.

Debug builds are usually way larger if debug info and assertions are
used, but without them the difference is far less - then, using
"optimize for size" or "optimize for speed" will make the release
build larger or smaller than the debug one...