This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
RFA/commit: [win32] cannot automatically find executable file [...] warning at GDB startup
- From: Joel Brobecker <brobecker at adacore dot com>
- To: gdb-patches at sourceware dot org
- Cc: Pedro Alves <palves at redhat dot com>
- Date: Mon, 21 Dec 2015 19:11:51 +0400
- Subject: RFA/commit: [win32] cannot automatically find executable file [...] warning at GDB startup
- Authentication-results: sourceware.org; auth=none
Hi Pedro,
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.
I think this patch is fairly straightforward, but I'll wait a few
days before pushing it, in case you'd like to suggest another way
to handle this issue.
Thanks!
--
Joel
---
gdb/windows-nat.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
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)
--
2.1.4