don't read symbols from sections with w permissions. For some reason
ppc-linux maps executables three times, not twice as on x86, and if
the w flag is ignored, we wind up reading debug info twice, getting
wrong redirections, and then it all goes to hell in a handbasket.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4139
This involved some serious nastyness from the Department of Cpp Abuse.
Memcheck still bombs on ppc32 for unknown reasons.
There are still endianness issues within these functions, I think.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4129
relies on --smc-support=all to work correctly. Hence it tests the
s-m-c support at least on x86. Jump through various hoops to defeat
vex's basic-block-chasing optimisation, which has an annoying habit of
making this test work correctly even without --smc-support=all.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4123
via the use of self-checking translations. (Friendly platforms which
have icache-invalidation instructions we can observe, such as ppc32,
are already handled correctly.) This should finally fix the
longstanding problem of V incorrectly handling calls of statically
nested functions (a gcc extension), and more generally make it a lot
easier to use V to debug dynamic code generation systems.
Since self-checking is a large performance overhead, there is some
control via a command line flag:
--smc-support=none
Don't make any translations self-checking.
--smc-support=stack
Add checking code for translations taken from segments which
have the SF_GROWDOWN flag set -- stacks, basically.
This is the default. It should make gcc nested functions and
GNU Ada work correctly with no intervention from the user.
--smc-support=all
Make all translations self-checking. This is expensive and
you want to do this if you're debugging a JIT compiler or
some such.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4122
any of it, so as to avoid any problems arising from switching from one
scheme to the other half-way through.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4117
handling of integer EQ/NE, which can sometimes do better than the
naive scheme when the inputs are partially defined. I never was
convinced it was correct before, but now I am. Regtest to follow.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4115
that we currently support use the same handlers in the kernel without any
platform specific wrappers.
The final argument is a 64 bit argument however, which means that it
requires two registers on x86 and ppc32 and only one on amd64. The
reason it works in the kernel is that x86 and ppc32 calling conventions
inside the kernel work out correctly and the values get joined together.
For our purposes we make x86 and ppc32 use the generic veneer with
five arguments and amd64 use a platform specific one with four...
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4110
causes too much breakage. PIE builds are still possible, but you have
to say --enable-pie to get them now.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4108
