[SOLVED] - How to know at run-time if $DEBUGINFO is on?

[garlar27]

Hi,

Is there a way to know at run-time if $D ($DEBUGINFO) is on?

I tried

Code: Pascal  [Select][+][-]

1. {$IFDEF DEBUGINFO}Somecode{$ENDIF} // Somecode is not executed (appears grayed in the editor)
2. {$IFDEF $DEBUGINFO}Somecode{$ENDIF} // Compiler doesn't allow it
3.  

[440bx]

Hi,

Is there a way to know at run-time if $D ($DEBUGINFO) is on?

I tried

Code: Pascal  [Select][+][-]

1. {$IFDEF DEBUGINFO}Somecode{$ENDIF} // Somecode is not executed (appears grayed in the editor)
2. {$IFDEF $DEBUGINFO}Somecode{$ENDIF} // Compiler doesn't allow it
3.  

The keywords in your request are at run time.  As you probably already know, to find out at compile time, you can test if an option or directive is "active". 

Under Windows, to determine at run time if an executable was compiled with debugging information, two possibilities come to mind.

1. Examine the value of the "Pointer to symbol table" field found in the executable's file header.  If the debugging information is _embedded_  in the executable (it usually is), that field will be non-zero.

2. if the debugging information is _not_ embedded in the executable, IOW, it is in a separate file, there is _probably_ an indication of that somewhere in the PE file (which is the program.)  I cannot tell you what field(s) in the PE file should be checked because I never tell the compiler to put the debugging information in a separate file but, it's quite likely there is something in the executable that indicates that situation.

NOTE: most C compilers, notably MSVC, will put a reference to the external PDB file in the DEBUG directory but I don't know if FPC does that or not when it is told to put the debug symbols in a separate file.

HTH.

[Martin_fr]

At compile time: https://wiki.freepascal.org/Conditional_compilation#.24ifopt

At runtime, as 440bx said: Examine the file on the harddisk.

[440bx]

At runtime, as 440bx said: Examine the file on the harddisk.

or examine the executable's image that is loaded in memory which saves from having to open the executable's file on the hard disk.

[jamie]

You can always use an external file for the debugging file which brings the EXE down a lot.

 But anyways, if you are looking for a simple way to insert debug notes for you and have it removed with a simple switch for the release mode of your app, then use "Asserts" those you can keep in the source code but use a compiler switch to not compile them in later on.

 If you are looking to see if your app is running under a debugger then you'll need to do some deeper testing for that.

[440bx]

If you are looking to see if your app is running under a debugger then you'll need to do some deeper testing for that.

Under Windows, the simplest way to determine if an app is running under a debugger is to call the API IsDebuggerPresent().

[Thaddy]

This always works:

Code: Pascal  [Select][+][-]

1. // put in main unit
2. var
3.   DebugInfo:Boolean = {$ifopt D+}true{$else}false{$endif};  
4. begin
5. end.

[440bx]

This always works:

Code: Pascal  [Select][+][-]

1. program untitled;
2. // put this in your program file
3. var
4.   DebugInfo:Boolean = {$ifopt D+}true{$else}false{$endif};  
5. begin
6. end.

Yes, setting a flag at compile time which can be checked at runtime, as you showed above, is definitely the simplest way _and_ it is platform independent.

[Thaddy]

I added an extra edit. First example is for single file programs, my edit is for unit using programs.

Another trick (that is working in Delphi) is scan the sources for {$ifopt D+} and see what you can use there....

EDIT
this works on a bare program:

Code: Pascal  [Select][+][-]

1. program untitled;
2. begin
3.   {$ifopt D+}writeln('compiled with debuginfo'){$endif}
4. end.

Lazarus:

Code: Pascal  [Select][+][-]

1. procedure TForm1.FormCreate(Sender: TObject);
2. begin
3.   {$ifopt D+}Form1.Caption := Form1.Caption+'[debug mode]';{$endif}
4. end;  

     

Seems to work better than just {$if defined(debug)}

[garlar27]

Thank you very much!!!

I used this code since is easier to read even for newbies:

Code: Pascal  [Select][+][-]

1. Log('Stack Trace:' + {$IFOPT DEBUGINFO} LineEnding + GetDumpExceptionCallStack(E){$ELSE}'NO DEBUG INFO !!!'{$ENDIF});

[Martin_fr]

Just a note on the site, as I see you dump stacktraces on errors.

You can dump them in released versions of your app. Of course they will show with no line info, and appear useless.
But (with a few steps taken before release) you (and only you) can actually resolve them in the IDE.
That can be used to get more meaningful bugreports from users.

1) Compile your release with debug info.
2) Keep a copy of the exe (with debug info)
3) use "strip" to remove debug info from the file you will make public

Now if you get a stacktrace with no lines, but addresses only:
- Open View > Leaks and traces
- Paste the stacktrace.
- Press "resolve" and select the exe with debug info.
  This has to be the exact matching exe. So each release must have an build number, and you must know the build number to match it.

The IDE will (should) find the line info for you.

Before relying on this, you should test with your target app...

[garlar27]

Just a note on the site, as I see you ...

What about using an external file ( option -Xg ) instead of "stripping"?

I've seen that option but I never knew how to use it...

[Martin_fr]

Just a note on the site, as I see you ...

What about using an external file ( option -Xg ) instead of "stripping"?

I've seen that option but I never knew how to use it...

This should generally work with gdb. And IIRC fpdebug also deals with it.
You have to test, if leak and traces understand it. 
(This may even differ between fixes and trunk, since leak and traces switched from the fpc line-info reader to fpdebug)

In any case for it to work, the external .dbg file has to be in the correct place/folder (Afaik same as exe).

---
This option may be useful for embedded, where your target platform has not enough storage for an exe with debug info in it.
Otherwise I personally don't see the point in it.
Well if it works with leaks and traces, it save calling strip, so that is a point.

Note that sometimes strip can even clean symbols out of an exe, that was build without debug info.
Some symbolnames may be needed by the linker, and then can end up in the exe.

[garlar27]

Well, it didn't work
When pasting the following message in Leak and Traces shows nothing even after pressing resolve and choosing the binary or the .dbg file

Code: Pascal  [Select][+][-]

1. Program exception!
2. Stacktrace:
3.  
4. Exception class: EAccessViolation
5. Message: Access violation
6.   $00420E57
7.   $0042B3E5
8.   $0050FAF5
9.   $0052D010
10.   $0052D6E6
11.   $0052CF1D
12.   $0040DEE8
13.   $00504D71
14.   $0058C06F
15.   $004EC4FA
16.   $004ECB6B
17.   $005C29FD
18.   $7765635B
19.   $7764729C
20.   $77646A4D
21.   $77646713
22.   $74285AEF
23.  

But pasting the following message it works like a charm.

Code: Pascal  [Select][+][-]

1. Program exception!
2. Stacktrace:
3.  
4. Exception class: EAccessViolation
5. Message: Access violation
6.   $00420E57  TCUSTOMFORM__SHOW,  line 2317 of ./include/customform.inc
7.   $0042B3E5  TFORMMAIN__BUTTON1CLICK,  line 499 of mainfrm.pas
8.   $0050FAF5  TCONTROL__CLICK,  line 2864 of ./include/control.inc
9.   $0052D010  TBUTTONCONTROL__CLICK,  line 55 of ./include/buttoncontrol.inc
10.   $0052D6E6  TCUSTOMBUTTON__CLICK,  line 169 of ./include/buttons.inc
11.   $0052CF1D  TBUTTONCONTROL__WMDEFAULTCLICKED,  line 21 of ./include/buttoncontrol.inc
12.   $0040DEE8
13.   $00504D71  TWINCONTROL__WNDPROC,  line 5397 of ./include/wincontrol.inc
14.   $0058C06F  DELIVERMESSAGE,  line 112 of lclmessageglue.pas
15.   $004EC4FA  TWINDOWPROCHELPER__DOWINDOWPROC,  line 2513 of ./win32/win32callback.inc
16.   $004ECB6B  WINDOWPROC,  line 2671 of ./win32/win32callback.inc
17.   $005C29FD  PAGEWINDOWPROC,  line 105 of ./win32/win32pagecontrol.inc
18.   $7765635B
19.   $7764729C
20.   $77646A4D
21.   $77646713
22.   $74285AEF

may be I'm doing something wrong...

[Martin_fr]

I forgot, you may have to use dwarf (default for 64bit apps, but not for 32bits).
And on Mac, it only works in trunk.

Stabs is not supported.

I will have to test the feature myself again.

Edit:
Ok, right now it does not even accept the paste of the raw address-only data.
That needs to be fixed....