old-cross-binutils/gdb/ChangeLog

19 lines
392 B
Text
Raw Normal View History

2016-01-01 Joel Brobecker <brobecker@adacore.com>
* top.c (print_gdb_version): Change copyright year in version
message.
2016-01-01 Joel Brobecker <brobecker@adacore.com>
[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.
2015-12-19 14:21:01 +00:00
* config/djgpp/fnchange.lst: Add entry for gdb/ChangeLog-2015.
[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.
2015-12-19 14:21:01 +00:00
For older changes see ChangeLog-2015.
Local Variables:
mode: change-log
left-margin: 8
fill-column: 74
version-control: never
2007-08-09 22:44:38 +00:00
coding: utf-8
End: