views:

29

answers:

1

My setup is as follows:

  • OS: Windows 7 Home Premium 64-bit
  • Eclipse: Helios 3.6.1 64-bit with CDT and Photran
  • Java SE Runtime Environment: 1.6.0_21
  • Java Hotspot: 64-bit Server VM (build 17.0-b17, mixed mode)
  • Cygwin 1.7.2 (32-bit)

My initial test Fortran application simply prints 'Hello World!' and exits. The code builds and runs fine, albeit with the following 2 Warnings in the Problems tab in Eclipse

Description Resource    Path    Location    Type
Error launching external scanner info generator (gcc -E -P -v -dD C:/Users/Joe/workspace/.metadata/.plugins/org.eclipse.cdt.make.core/specs.c)  HelloFortran    Unknown C/C++ Problem
Error launching external scanner info generator (gcc -E -P -v -dD C:/Users/Joe/workspace/.metadata/.plugins/org.eclipse.cdt.make.core/specs.c)  HelloFortran    Unknown C/C++ Problem

The problem comes when trying to debug the app as a Local Fortran Application which results in this error:

cygwin warning:
  MS-DOS style path detected: C:\Users\Joe\workspace\HelloFortran
  Preferred POSIX equivalent is: /cygdrive/c/Users/Joe/workspace/HelloFortran
.gdbinit: No such file or directory.
  CYGWIN environment variable option "nodosfilewarning" turns off this warning.
  Consult the user's guide for more details about POSIX paths:
    http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
auto-solib-add on
Undefined command: "auto-solib-add".  Try "help".
Error: dll starting at 0x76ba0000 not found.
Error: dll starting at 0x75230000 not found.
Error: dll starting at 0x76ba0000 not found.
Error: dll starting at 0x76aa0000 not found.
[New thread 7060.0x10dc]
[New thread 7060.0x16c0]

I'm guessing the entry points aren't found because it's expecting 32-/64-bit DLL and getting the other type (correct me if I'm wrong). The GDB version is as follows:

GNU gdb 6.8.20080328 (cygwin-special)
GDB configured as "i686-pc-cygwin"

Running GDB from the command-line gives:

[New thread 5768.0x15a0]
Error: dll starting at 0x76ba0000 not found.
Error: dll starting at 0x75230000 not found.
Error: dll starting at 0x76ba0000 not found.
Error: dll starting at 0x76aa0000 not found.
[New thread 5768.0x46c]
hellofortran () at ../HelloFortran.f90:1
1    program HelloFortran
Current language: auto; currently fortran

If I'm reading that correctly the application does run in GDB and I am able to step through it, but what are the missing DLL errors about?

Dependency Walker gives the following errors for my HelloFortran.exe

Error: Modules with different CPU types were found.
Warning: At least one delay-load dependency module was not found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.

The missing DLLs seem to be IESHIMS.DLL (2) which from my quick research doesn't seem to be a big issue but I don't see any reason my application would need to reference this DLL so I don't think this is leading to the errors in GDB.

All of the modules have a CPU type of x64 except for:

CYGGCC_S-1.DLL
CYGGFORTRAN-3.DLL
CYGWIN1.DLL
HELLOFORTRAN.EXE

which have a CPU type of x86

I'm concerned the missing DLL errors could harm my ability to debug my program properly (although the program will eventually run on a Unix-based HPC so I shouldn't run into these issues there since all those DLLs seem to be to do with Cygwin).

My questions:

  • Why do I get missing DLL errors? (Would switching to 32-bit versions of Eclipse/JVM etc fix this?)
  • Am I okay to continue, or should I solve the missing DLL errors (and if so, how)?

Edit: My test program is as follows:

program HelloFortran
    ! Force variable declaration
    implicit none

    ! Print 'Hello World!' to the main output
    write (*,*) 'Hello World!'

    ! End program
end program HelloFortran
+1  A: 

Why do I get missing DLL errors?

When Win/x64 sends a DebugEvent to 32-bit process about a 64-bit DLL that is part of that process, it necessarily truncates the load address (64-bit load address doesn't fit into 32-bit LPVOID). The end result is that the debugger sees a DLL load event, but can't find any DLL at that address; so warns you.

(Would switching to 32-bit versions of Eclipse/JVM etc fix this?)

No: this is fundamental to debugging any 32-bit process on x64 (at least with 32-bit debugger). I think you would get rid of the warning if you use x64 version of GDB, but I am not sure if GDB/x64 can debug 32-bit processes on Windows (x86_64 GDB has no trouble with i386 processes on Linux due to "multi-arch" support; I don't know if "multi-arch" is present in Windows version).

I'm concerned the missing DLL errors could harm my ability to debug my program properly

You shouldn't be.

I don't see any reason my application would need to reference IESHIMS.DLL

What made you think it's IESHIMS.DLL?

More likely what you see is WoW64.dll and friends. Every 32-bit application running on Win/x64 references WoW64.

Employed Russian
Dependency Walker said it found 2 missing load-dependent DLLs in my .exe which it listed as IESHIMS.DLL (2) - so that was my thinking.
Joseph Earl
I tried with a 64-bit version of GDB from http://www.equation.com/servlet/equation.cmd?fa=gdb
Joseph Earl
The 64-bit version seems worse.The GDB version is 7.2 and configured as "x86_64-w64-mingw32"When running the program with the 64-bit GDB I get a lot of warnings:warning: 'C:\Windows\system32\ntdll.dll': Shared library architecture 4 is not compatible with target architecture i386(and 9 others very similar to that) Then the last warning is different - warning: cYgstd 28ccd5 d 3The program works and exits normally as with the 32-bit GDB. Think I'll stick with the 32-bit GDB for the time being, thanks for all your help.
Joseph Earl