This is the mail archive of the gdb-cvs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[binutils-gdb] [win32] cannot automatically find executable file [...] warning at GDB startup


https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=aec47d1d54be415050bbd3ccb93c0157d60ed92d

commit aec47d1d54be415050bbd3ccb93c0157d60ed92d
Author: Joel Brobecker <brobecker@adacore.com>
Date:   Sat Dec 19 09:21:01 2015 -0500

    [win32] cannot automatically find executable file [...] warning at GDB startup
    
    The following change...
    
        commit 43499ea30db2a866412c86952c7e1d7b158d806f
        Date:   Tue Nov 17 15:17:44 2015 +0000
        Subject: [C++/mingw] windows-nat.c casts
    
    ... causes a small regression in GDB, where we get the following
    warning at startup:
    
        % gdb
        C:\[...]\gdb.exe: warning: cannot automatically find executable file or library to read symbols.
        Use "file" or "dll" command to load executable/libraries directly.
        GNU gdb (GDB) 7.10.50.20151218-cvs (with AdaCore local changes)
        [...]
        (gdb)
    
    The warning comes from _initialize_loadable which tries to dynamically
    load some symbols from kernel32.dll and psapi.dll, and in particular:
    
      hm = LoadLibrary ("psapi.dll");
      if (hm)
        {
          GPA (hm, EnumProcessModules);
          GPA (hm, GetModuleInformation);
          GPA (hm, GetModuleFileNameEx);
        }
    
    The problem is that the new GPA macro assumes that the name of
    the variable we use to point to the function, and the name of
    its associated symbol are the same. This is mostly the case,
    except for GetModuleFileNameEx, where the name is provided by
    the GetModuleFileNameEx_name macro (defined differently depending
    on whether we are on cygwin or not). As a result, the dynamic
    resolution for GetModuleFileNameEx returns NULL, and we trip
    the following check which leads to the warning:
    
      if (!EnumProcessModules || !GetModuleInformation || !GetModuleFileNameEx)
        {
          [...]
          warning(_("[...]"));
        }
    
    This patch fixes the problem by calling GetProcAddress directly,
    rather than through the GPA macro, but in a way which hopefully
    avoids the C++ compilation warning that the previous patch was
    trying to get rid of.
    
    gdb/ChangeLog:
    
    	* windows-nat.c (_initialize_loadable): Fix computing of
    	GetModuleFileNameEx.

Diff:
---
 gdb/ChangeLog     | 5 +++++
 gdb/windows-nat.c | 3 ++-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index c708733..a741e69 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,8 @@
+2015-12-22  Joel Brobecker  <brobecker@adacore.com>
+
+	* windows-nat.c (_initialize_loadable): Fix computing of
+	GetModuleFileNameEx.
+
 2015-12-21  Joel Brobecker  <brobecker@adacore.com>
 
 	* gdbtypes.c (create_array_type_with_stride): Fix indentation.
diff --git a/gdb/windows-nat.c b/gdb/windows-nat.c
index a7132d6..5256037 100644
--- a/gdb/windows-nat.c
+++ b/gdb/windows-nat.c
@@ -2830,7 +2830,8 @@ _initialize_loadable (void)
     {
       GPA (hm, EnumProcessModules);
       GPA (hm, GetModuleInformation);
-      GPA (hm, GetModuleFileNameEx);
+      GetModuleFileNameEx = (GetModuleFileNameEx_ftype *)
+        GetProcAddress (hm, GetModuleFileNameEx_name);
     }
 
   if (!EnumProcessModules || !GetModuleInformation || !GetModuleFileNameEx)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]