This is the mail archive of the gdb-patches@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]

Re: [patch+NEWS] Avoid false valgrind warnings on linux_ptrace_test_ret_to_nx


On Wed, 20 Feb 2013 18:30:18 +0100, Pedro Alves wrote:
> On 02/20/2013 04:08 PM, Jan Kratochvil wrote:
> > OTOH here you ask for the opposite, unchecked inclusion of include file
> > which is very complicated
> > with compiler-dependent parts and arch-specific code,
> > which all seem to me to possibly cause compilation failures.
> 
> Now I'm at a total loss.  I have no idea what you're considering
> very complicated, and what needs to be compiler dependent.

> All I was thinking was something like the patch below.

It primarily misses the --with-valgrind feature: to error out when user does
want the (valgrind) support but system does not have the prerequisite files.

As the packaging system may omit some of the prerequisites (such as when PKG
splits out its PKG-devel subpackage) one needs to ensure such build will fail.
We do not want to quietly build new GDB missing some of the expected features.
--with-valgrind makes this easy.  Otherwise the packager needs to place in
the .spec file:
	grep HAVE_VALGRIND_VALGRIND_H gdb/config.h
Moreover multiple times as config.h gets sometimes rebuilt during some build
scenarios.

For example Fedora gdb.spec already has such a hack because there is no
corresponding --with-*/--enable-* option for this one:
	! grep '_RELOCATABLE.*1' gdb/config.h

It may be clear I do not want to introduce more such greps there.


So with the --with-valgrind requirement we end up discussing whether these 8
lines of code should or should not be there:

+    AC_MSG_CHECKING([for RUNNING_ON_VALGRIND macro])
+    AC_CACHE_VAL(gdb_cv_check_running_on_valgrind, [
+      AC_LINK_IFELSE(
+       [AC_LANG_PROGRAM([[#include <valgrind/valgrind.h>]],
+         [[return RUNNING_ON_VALGRIND;]])],
+       [gdb_cv_check_running_on_valgrind=yes],
+       [gdb_cv_check_running_on_valgrind=no])])
+    AC_MSG_RESULT($gdb_cv_check_running_on_valgrind)

I believe there is a real risk there can exist old system(s) on non-x86* arch
having valgrind/valgrind.h available but failing to build RUNNING_ON_VALGRIND.

Sure people have different opinions what is useful and what is just a bloat.
Although when I already wrote the code I do not find such a serious problem to
put there such 8 lines to sanity check the compatibility.


Jan


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