In C++Builder(5,6...XE4) IDE if I set a breakpoint on, say: memset(x,0,sizeof(y)), and try to step into memset(), the debugger would silently step over it. In contrast, the VS debugger steps into the asm rtl sources. Is there a way to let the CBuilder debugger walk through rtl sources?
The project is compiled with debug info, rtl is linked statically, no delphi vcl/rtl involved.
Related
I just bought XE2 version, installed the update 1 ISO, and made my Open Source projects compile with it.
In fact:
I added the source code paths of the library to the general settings IDE (for all platforms I use, i.e. Windows 32 bit and 64 bit up to now);
I compiled the TestSQLite3.dpr regression tests of our framework - no problem: EXE is compiled and all tests passed;
I've a strange issue with the IDE background compilers: even if the project compiled, the IDE displays some errors about unknown files (not in the bottom compiler messages, but in the top of the classes navigation tree - left to the source code editor), and in the .dpr source code, the unit names are underlined in red, and I'm not able to navigate inside the source (using Ctrl+Click on a symbol).
I've added the source code paths of the library to the project options (for Win32/Win64 - even if it was already set at the global IDE level). Now the errors about unknown files disappeared, but the unit names are still underlined in red in the source code, and the Ctrl+Click does not work.
The TestSQLite3.dpr source code do not specify the full path of the units:
uses
{$I SynDprUses.inc}
Windows,
Messages,
SysUtils,
Classes,
SynCrypto,
SynCrtSock,
SynCommons,
SynDB,
SynOleDB,
SynDBOracle,
(...)
In the above lines, SynCrypto, SynCrtSock, SynCommons are underlined in red.
My actual guess is that full paths are needed in the .dpr (SynCrypto in '..\SynCrypto.pas'). I did not test this because I don't have XE2 at work.
Since there was no issue with the previous IDE with this kind of source code (it worked from Delphi 6 up to XE), I wonder if there is a possibility of regression, or a new option not available with the previous version of the IDE (probably platform-based) which I did not set properly. Or perhaps the full path is now needed in .dpr - but this sounds like a regression in the Code/Error Insight compiler to me.
I asked the question to Dr Bob (by whom I bought the XE2 license - since the 1 $ = 1 € equation sounded a bit unfair, I wanted at least to have a real Delphi expert for being my reseller).
Here is his answer:
You did not make a mistake. The problem is that the there are three
compilers in XE2 (like in previous versions of Delphi): the real
compiler (which works fine), the Code Insight compiler (which is
faster), the Error Insight compiler (which must be even more faster),
and the syntax highlighting parser (which is the fastest).
XE2 introduced a number of features that made the normal compiler
slower, and gave the Code Insight and Error Insight compilers a bit of
trouble. First of all, we have the new targets: Win32, Win64 and OSX
which cause the search paths to be different for each target (see
$PLATFORM directive), as well as build configuration, although there
is only one "Library path" for each PLATFORM (and not for the build
configurations).
The second complexing factor is the dotted unit names (scoped unit
names) that were introduced. Windows is no longer Windows, but
Winapi.Windows.
My guess is that these two additional complexing factors cause
problems for the Code Insight and Error Insight compilers. Note that
the real compiler still works. But the Error Insight shows incorrect
errors, and the Code Insight doesn't always work for these units.
You could try to explicitly add them to the project again (in which
case the full path will be used, like you mention in your question on
stack overflow as well).
So I'm afraid this is some regression...
Edit at closing question:
First point is that adding full paths:
SynPdf in '..\SynPdf.pas',
in the .dpr did let the files been found - but the background compiler is still lost, unable to find a class declaration in this body.
Just another regression sample:
var Thread: array[0..3] of integer;
Handle: array[0..high(Thread)] of integer;
Is a perfectly safe syntax, compiles just fine, was interpreted by the previous Error Insight compiler without any problems (works since Delphi 5), but fails under XE2.
I'm a bit disappointed about XE2 IDE. Compiler makes it work. But IDE is really disappointing. It is not usable, from my point of view. I'll continue using Delphi 7 as my main editor, and just use XE2 as cross-platform compiler and debugger.
Might be related to what Barry Kelly mentions here:
http://blog.barrkel.com/2011/10/delphi-xe2-compiler-performance.html
I have an application written in Delphi 7 which uses a c++ dll written in BCB 5.
I want to debug this dll from the Delphi IDE is this possible?
If it's possible which are the steps to debug?
As additional information I have the full source code of the dll.
It has been a while since I have dealt with C++ / Delphi together. But if I remember correctly, you can use the BCB IDE to run the Delphi application (compiled already) that uses your DLL. Basically, in your project settings in BCB, you can set a program to run when you click the "run" button, and I believe that you will be able to set breakpoints and stuff that will be caught when functions of your DLL are being called by that application. Still, this implies that you have BCB.
My recollection, and it's been a while since I last tried this, is that you need the C++ Builder IDE to do this.
It should be possible:
I have done it quite often to debug a BCB5 dll within the Delphi 6 IDE. My delphi 6 application uses the DLL and I can then step from the delphi code into the bcb code (and back). So I might work with Delphi 7 too.
Delphi isn't configured by default to do that. At that time I found an explanation on the web how to do it. Not sure, but it might have been the following page: http://www.delphifaq.com/faq/delphi/delphi_ide/f178.shtml
You will also need to compile the dll in debug mode and to indicate the path to the source code of the dll in the project options of your delphi application.
I have a Delphi app that we're migrating to C++. One thing I often do while debugging my Delphi code is step into the VCL itself to understand exactly what's going on, to track some bugs. Is this possible in C++Builder?
Suppose I am in C++Builder and I call "ShowMessage". Can I step into that call in my debugging session and switch to Pascal on the fly?
It is possible, but you must change two settings.
You must turn off the Dynamic RTL in the linker settings.
You must disable linking with runtime packages in the package settings.
How do I debug JVCL code using C++Builder? I enabled building debug DCUs when I installed JVCL, I turned on "use debug DCUs" under my project's Delphi settings (there doesn't appear to be an analogous option under C++ settings), and I disabled building with packages. In spite of all of this, single step still skips over JVCL code, and if a JVCL function shows up in a stack trace, double-clicking on it only shows disassembly.
Debugging RTL and VCL code works fine; it's only JVCL code that I'm having problems with.
Any ideas?
Edit: I've also noticed that JVCL debug DCUs work fine for Delphi apps. I tried doing building my project while Process Monitor was running, and for a C++Builder app, it's not even trying to find the JVCL DCUs (so it's apparently not just a problem with my search path). However, it does look for and find DCUs for core VCL files. So apparently C++Builder is determining its dependencies differently than Delphi, and apparently JVCL dependencies are being treated differently than core VCL dependencies, but I don't know how or why.
Setting the "use debug DCUs" option adds the contents of the debug path option onto the front of the search path option so that next time your code is linked, the linker will use the debug files instead of the normal files.
When you've checked that box, make sure that the directory that contains the debug versions of the JVCL DCUs is on your search path. If it's not, then add the JVCL path to your debug path (right after $(BDS)\Lib\Debug) and toggle the "use debug DCUs" option to reset the search path.
I'm building a project that uses the JVCL plugin system, which relies on runtime Delphi packages, and ever since I added it to my project, debugging has become a nightmare because I'm no longer able to step-trace into the source of any VCL or RTL units. They're all marked as gray dots in the debugger, (when the relevant functions appear at all in the call stack; sometimes I get very strange results,) and it's driving me crazy. Does anyone know how to get my debug DCU functionality back? (Aside from the obvious: rip out all the plugin-related code. That would work, but it wouldn't really help.)
Edit: Just to be clear, I can trace anything else in my project. JVCL code. Other 3rd party libraries. My own code. All of it shows up just fine in the debugger. Just not the Delphi RTL and VCL code--the stuff that the compiler option "use debug DCUs" is supposed to grant you access to.
This is working as designed.
When you are building with packages, you are executing the package code, and not using any DCU's. Therefore, the DCU's are compiled in, and you don't get access to the Debug DCU's.
You can either turn off packages altogether, or don't compile with the specific packages you want to debug. You can choose what packages should be used or not used, and the ones that aren't used will be "debuggable" with the Debug DCU's.
Packages are just DLLs. You have to include the debug info into those to be able to debug them, which is what you want to do. So you would need to have DEBUG packages for the VCL and RTL, not debug dcus. The debug dcus are not even needed anymore when you use prebuilt packages.
It could be the DCU's you have are out of date, so the debugger doesn't step into the code.
Usually deleting all the DCU's then doing a Build All will fix this.
You may need to delete DCU's in the search path too, just to be sure. Make a backup first of course...