How to tell if a binary is release or debug in both win and *nix

Question

Is there a simple command line utility to inspect binaries like executable and dynamic libraries to tell if they are release or debug versions? Is there anything like that on *nix or windows?

"Debug" and "Release" don't have specific meanings; they are just ways of referring to a bundle of options, which could be different in different projects. Do you mean whether something was build with debugging symbols and left unstripped? — smorgan, Apr 30 '09 at 17:33
*Do you mean whether something was build with debugging symbols and left unstripped? * Yes. — , Apr 30 '09 at 19:59
Possible duplicate of [How can I tell if a library was compiled with -g?](http://stackoverflow.com/questions/1999654/how-can-i-tell-if-a-library-was-compiled-with-g) — Ciro Santilli OurBigBook.com, Sep 13 '16 at 12:42

Bob Yoplait · Answer 1 · 2013-08-19T09:16:55.900

30

for C++ on Linux, you can do:
```
    objdump --source yourbin |grep printf
```
Replace printf with whatever function call you do. If it is debug, it will display all the actual source code call you do. If it is release, it will just display the founded symbol from the symbol table.
for C++ on Windows, you can use depends.exe and see if it depends on MSVCRT (release) or MSVCRTD (debug)

edited Aug 19 '13 at 09:16

answered Mar 16 '11 at 18:38

Bob Yoplait

2,421
1
23
35

Not sure if this works `objdump --source hello32* | grep printf` in this `gcc -m32 -g -o hello32_dbg hello.c` and this case `gcc -m32 -o hello32 hello.c` returns nothing – Wakan Tanka Apr 22 '15 at 08:10
Just checking, do you call printf in hello.c ? – Bob Yoplait Apr 22 '15 at 16:52
Actally i was using puts – Wakan Tanka Apr 22 '15 at 23:29
1

Note that for Windows (MS compilers), the name of the DLL you need to look for depends on the version of the C++ runtime you link against (mostly, that depends on the version of Visual Studio). The DLL names haven't been MSVCRT/MSVCRTD in well over a decade. – Euro Micelli Nov 22 '16 at 17:56

score 19 · Answer 2 · answered Apr 30 '09 at 17:33

19

On linux you can use the "file" command even for dynamic libraries. If it says "stripped" than all debugging symbols are stripped out. If it is saying "not stripped" it is the opposite

answered Apr 30 '09 at 17:33

Norbert Hartl

10,481
5
36
46

20

It is possible to have a non-stripped release or a stripped debug build. – leander Apr 30 '09 at 17:36
I'm not sure what you mean by release or debug build. I assumed that a programme/library will be build with debug symbols for debugging and will be stripped for shipment. So the debug or release are implicit to the way you use it. You can have every combination because it depends on how you package it. – Norbert Hartl Apr 30 '09 at 20:37
8

not true, stripping symbols is independant of debug or release versions – Bob Yoplait Mar 16 '11 at 18:40
https://stackoverflow.com/questions/22682151/difference-between-a-stripped-binary-and-a-non-stripped-binary-in-linux/22682228#22682228 – parasrish Jul 19 '18 at 05:24

Macke · Answer 3 · 2013-08-05T10:45:05.380

3

For Windows, the Dependency Walker has optional cmd-line output listing every dll the exe loads (and their dependencies). Run that through grep and see if the msvcrt-dll popups with a d or not.

This only works if it's dynamically linked. Otherwise it might be trickier.

You could perhaps grep for certain functions that are different in debug/release, if those strings are visible in the executable.

If your apps doesn't use the runtime at all, it'd be pretty tricky.

edited Aug 05 '13 at 10:45

answered Apr 30 '09 at 17:33

Macke

24,812
7
82
118

@Andre Having debug info is not the same as being built in debug or release. What do you mean? – Macke Mar 08 '17 at 07:44
1

See the comments by leander and smorgan above. It is possible to have a non-stripped release build, but also to strip a debug build. The distinction "Debug" vs "Release" is a bit vague. For some people, e.g. you "Debug" means: built agains the debug runtime. For others, it may mean" built without the NDEBUG define. And for others it may mean: Non-optimized or just: with debug symbols. – André Mar 30 '17 at 08:08

leander · Answer 4 · 2009-04-30T20:15:42.087

For unix: with ELF executables you may be able to use objdump or nm to look at the symbol tables for the executable (note that this will work a lot better if it's not stripped). The presence or absence of certain symbols will tend to indicate a debug or release build. (As to which, that probably depends on what libraries you're using, etc. You'd have to do a bit of digging to find common ones; feel free to suggest things to look for in comments, and I'll update the answer.)

For Windows: the dependencywalker suggestions are good. For command-line equivalents, you can find dumpbin in most Visual Studio installations and it's somewhat equivalent to objdump on *nix. You may also be able to find an nm or objdump in e.g. msys or cygwin that'll work on some windows exe files.

I am new to Mac OS X which is what I am using. But apparently objdump does not come with Xcode. nm is available but the only difference I can see is that the debug version simply contains a lot more stuff. — , May 01 '09 at 15:17

score 2 · Answer 5 · answered Apr 30 '09 at 17:34

There's not much to go on. If you open an assembly in Reflector, you can look for the Assembly Attribute:

[assembly: Debuggable(DebuggableAttribute.DebuggingModes.DisableOptimizations | DebuggableAttribute.DebuggingModes.EnableEditAndContinue | DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints | DebuggableAttribute.DebuggingModes.Default)]

But apparently that's added to release mode as well.

If it's your own assembly than the solution is to use some preprocessor directives.

#ifdef DEBUG
[MyAttribute("foo")]
#endif

edit: Sorry, I assumed .NET. There goes my hammer.

Glad that you assumed .NET because that's what brought me here and your answer pointed me into the right direction. In VS2010 the attribute is in both Debug and Release builds but the argument "list" is different. — Piotr Owsiak, Dec 21 '11 at 18:43

Piotr Dobrogost · Answer 6 · 2009-04-30T17:45:47.250

Most often debug versions of both executables and libraries are linked against debug version of runtime. On Windows there's a name scheme for debug/release versions that some follow, MS among them. The name of debug version of a library should end with d. You can use tool like Dependency Walker (http://www.dependencywalker.com) to see on what libraries your executable or library depends. If you find debug versions of runtime libraries there there is a big chance your executable or library was built in debug mode.

This however works only if

you can tell by looking at a name of runtime which version it is (it follows some naming scheme like the one I described above)
your executable/library is linked against dynamic runtime not static one. In the second case the runtime gets pulled into executable/library and it's no longer a dependency
you are on Windows :)

score 0 · Answer 7 · answered Nov 03 '13 at 13:55

You can use filever.exe.

filever.exe <my binary file>
--a-- W32i   APP   -         1.0.0.0 shp     25,600 11-03-2013 <my file>

To get filever, you can download the support tools for windows xp.

If you moved to Windows 7 or above (like most windows users), you can download it, open it via winzip.

Then extract filever from support.cab.

It works for Windows 7 just fine.

score 0 · Answer 8 · answered Apr 18 '14 at 07:05

0

Use depends.exe to find out which version it is. when You open the file through depends walker it will show file which are needed. By seeing the list of system32 files you can it whether it is debug or release

answered Apr 18 '14 at 07:05

Srikanth Baratam

11
2

How to tell if a binary is release or debug in both win and *nix

8 Answers8