Silverfrost Forums

Welcome to our forums

Debugging a DLL missing the symbols

26 Oct 2009 12:35 #5250

I try to debugg a FTN95 DLL which is called by a C++ DLL. The C++ DLL is created with VisualStudioExpress and the FTN95 DLL with Silverforst FTN95 Express. I can debugg with Viusual Studio the C++ part. I try to open my Silverforst project and connect it to the runtime process. But if I start the process the progamm didn't stop at my breakpoints. So I try to make an error inside (Division by 0 ) to force the start of a debugger. And a message comes from Silverforst debugger, but it looks like that he didn'T find the symbols. Only Disassembling code is possible to see. How can the debugger find the symbols? I compile with /DEBUG and /FULL_DEBUG.

26 Oct 2009 7:47 #5253

See if you can compile and link the C++ DLL using SCC, the C++ compiler provided with FTN95. If you can then compile it using one of the debugging options /DEBUG etc. Then you should be able to step through your code.

27 Oct 2009 12:51 #5254

Hmm, it should work. How are you debugging it, are you using sdbg?

27 Oct 2009 7:07 #5257

In the properties of my FTN95 project I have tried for the debugger type (Compiler options - Debugging) Salford SDBG and also Visual Studio Integrated. But both have the same result as descriped before.

But I think the problem is somewhere else. For more explanation: I have a folder with my fortran-project. I compile it and get a LIB and a DLL. Then I copy the fortran.lib to my C++ project in another folder an compile that. The result is another DLL. These DLLs are for grafical programm that can use DLLs, if I put them in a certain folder of that programm I can use them. So I copy the c++-DLL in that certain folder and that all run well I have to copy the Fortran-DLL in the root of my grafical programm. I think that the debugger is missing the symbols. Is there a special file with the symbols and I have to copy it in the root folder where my fortan.dll is in ?

27 Oct 2009 8:18 #5260

Can you confirm that you are using SCC to compile your C++ code rather than the Microsoft compiler? Robert will be able to say if this is necessary but from my perspective it is certainly advisable.

27 Oct 2009 8:24 #5261

I will try to use SCC, but I have to look how to do. I just tried to do all with PLATO. But in the moment I have a .DEF file that PLATO don't want.

27 Oct 2009 5:24 #5267

If the DEF file is for exports then all you need to link with SLINK and use exportall. You can do this from Plato.

2 Nov 2009 9:36 #5299

Hi Werner

The debug information for a FTN95 DLL is in the DLL itself (so you cannot misplace it). A Visual C++ DLL quite often has a .pdb file present which contains the debug information -- but sdbg cannot read .pdb files anyway. It can read the COFF though which should be enough to allow you to debug the Fortran part.

Is your example fairly small and can you send it us to look at?

20 Nov 2009 4:06 #5400

Hello! May problem still exists. Now I have had the time to compile and link all with PLATO. So for the first time the DLLs are compiled without an error. But now I must debugg it with PLATO. May C++ DLL is called by another programm. So I want in the first step have a breakpoint in my C++ DLL. In Visual C++ I can attach the DLL to a running process and than set my breakpoints etc.
How can I debug with PLATO? I don't find a possibility to set a breakpoint or to attach to a process.

Thanks Werner

20 Nov 2009 4:52 #5403

You will need to compile the exe and the DLL using one of the debugging options such as /check.

Then I would suggest that you start up the exe using SDBG directly. Put the DLL in the same folder as the exe. When SDBG starts up, open the source code for the DLL in SDBG and set your breakpoint manually.

I think that this should work.

4 Dec 2009 11:09 #5475

Again still big problems. I try to explain my problem from the beginning;

I have a programm with no source code. It is a graphical programming tool. For that tool I have a DLL-Frame in C++ to make a AddOn to that tool. When I am finished with the creation of my AddOn-DLL, I have to put it in a certain folder of the Tool and after Start of the tool I can use the DLL-Function. That is the base scenario.

My AddOn calls from that Frame-DLL in C++ a function from a fortran DLL.

I create my Fortran-Dll with Plato. Than I also create my C++ Dll with Plato with a reference to my fortran-DLL. That looks all ok. Than I but my C++ Dll in the certain folder of my Tool and the fortran-Dll in the base folder of my tool. That is necessary that all runs well.

But now I want to debug with SDBG, because I have an error somewehre in my DLLs, so that the tool is crashing. Waht I have to do? My C++ Dll is in the folder c:\xxx\server\dll My Fortran DLL is in the folder c:\xxx\server The sourcecode is in d:\silverfrost and the existing subfolders.

I try to start SDBG with 'run to cursor' in my PLATO. but it didn't stop. I try to start SDBG from the console. Than SDBG stops in NTDLL.DLL. But I only see some assembler code. I also try to set SOURCEPATH to d:\silverfrost and all subfolders, also added the c:\xxx folders , but also no success.

Any idea?

5 Dec 2009 11:24 #5479

Werner

Can you send us the program so we can try and see what is going on? We don't need the source files at least not to find out why sdbg is stopping in ntdll.

6 Dec 2009 6:28 #5486

Hello Robert,

thank you for your answer. I think that I have to make tomorrow another try, because I have some new idea. I talked with the programmers of the Tool, and maybe I set my breakpoint to a wrong place. So I will try tomorrow and will write here the result.

7 Dec 2009 3:55 #5497

ok, here next part of the endless story. I sit together with the programmers of the Tool and we saw that the major problem in the moment is, that the stack is not correctly handled. I delete all Fortran part and only have C++ DLL generate with PLATO and then the tool crashes, because a wrong stack. The programmers told me, that there is a problem that the stack is handeld outside and inside the procedure and it should only be done once. We try some 'C' extern, stdcall and something else in the C++ Dll but all with the same result.

OK, so what can I do? Is there a possibility to download the source of my DLL somewhere? I don't know how to do.

7 Dec 2009 7:30 #5499

By default FTN95 does not use STDCALL and assumes that the DLLs it calls upon also do not use STDCALL.

If you want to use a third party DLL that uses STDCALL then the simplest approach is to import it using /import_lib on the command line.

Within a Plato project, a reference can be configured to use STDCALL. In the Project Explorer wiindow, add a reference and then right click on it to change its properties.

For more general instructions, search for STDCALL in the FTN95 help file (FTN95.chm).

8 Dec 2009 8:12 #5508

Next and maybe the last try before switching back to VisualStudio

The ThirdParty Tool has a frame C++ programm for the user DLL. An example of a subroutine for VisualStudio C++ is here

#define DLL __declspec(dllexport)

DLL DWORD GetDllVersion(void)
{
  return (DLL_INTERFACE_VERSION_HIGH | 1);
}

So, SCC don't unterstand __declspec .. Does anyone knows how I have to change this code, if I want to compile it with SCC, so that all is well with the calling conventions etc?

If I change it to :

#define DLL 

DLL DWORD WINAPI GetDllVersion(void)
{
  return (DLL_INTERFACE_VERSION_HIGH | 1);
}

than I can translate and a part of the programm is running, but I have the problem with the stack handling

Thanks Werner

9 Dec 2009 10:22 #5513

OK, I climbed over the first little hill.

the code in the right way must be:

#define DLL extern 'C'

DLL DWORD GetDllVersion(void) 
{ 
  return (DLL_INTERFACE_VERSION_HIGH | 1); 
} 

It could be so easy. The problem was the WINAPI. Because WINAPI is STDCALL for windows and CDECL for WIndows CE. So I throw WINAPI away. But now the Tool which calls my DLL is C++ and here the 'name mangling' is done. That means, as I unterstand, that all the parameters will be checked. So that my DLL runs well with the Tool I have to write EXTERN 'C' for the subroutines and name mangling is switched off for them. And now all runs well. So, no I am back at my first problem to debugg this DLL. I keep on trying.

9 Dec 2009 12:48 #5515

Did you ever get to reading the help file on this subject?

10 Dec 2009 10:16 #5520

Hello Paul,

yes I have read the help file. But I have also to search a lot in internet to find this solution. In the help file I found only that FNT95 ( and that is Fortran) don't use STDCAL. But my problem is in C++ with the SCC compiler. In the help of SCC,I found nothing about the used calling conventions there. I dont know what SCC use instead of STDCAL.

But I get enlightened 😮ops: when I read 'List of calling Conventions' and 'Name mangling in C++' from David Bolton at httpt://cplus.about.com. Sorry if I get on your nerves, but normaly I don't have to handle with these things.

10 Dec 2009 10:35 #5521

FTN95 does not use STDCALL by default but you can use the keyword F_STDCALL. There is also a load of other stuff about STDCALL and in particular how to call C++ functions that use STDCALL.

You can also import from a Fortran library when that library uses STDCALL by using the command line switch /import_lib.

Please login to reply.