svn merge -r11143:HEAD svn://svn.valgrind.org/valgrind/branches/MACOSX106
There were some easy-to-resolve conflicts.
Then I had to fix up coregrind/link_tool_exe*.in -- those files had been
added independently on both the trunk and the branch, AFAICT. I just
overwrote the trunk versions with the branch versions.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11194
the changes to do with reading and using ELF and DWARF3 info.
This breaks all targets except amd64-linux and x86-linux.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10982
with #190429.
This patch (originally from Jakub Jelinek) makes the redir of strlen
in ld.so on amd64-linux ld.so mandatory, but only for glibc 2.10 and
above. For glibc-2.2 (our earliest supported version) to glibc-2.9
it is still optional.
Also, makes more verbose, the message that is printed if a mandatory
ld.so redirection on Linux cannot be set up.
Is believed to fix#190429.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10689
I tried using 'svn merge' to do the merge but it did a terrible job and
there were bazillions of conflicts. So instead I just took the diff between
the branch and trunk at r10155, applied the diff to the trunk, 'svn add'ed
the added files (no files needed to be 'svn remove'd) and committed.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10156
DARWIN branch. A big ugly DARWIN/trunk sync commit, mostly to do with
changing the representation of SysRes and vki_sigset_t. Functionality of
the trunk shouldn't be changed by it.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9876
the stack; instead use a stub in m_trampoline.S. This makes it
possible to deliver signals on non-executable stacks, and makes the
behaviour consistent with x86-linux and amd64-linux.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6813
memcheck, and they are hard to get rid of and hard to suppress. So
add a bootstrap strlen function and redirect to it right from the
start. This fn only replaces the strlen in ld.so; the "normal"
redirect mechanism still replaces the strlen that glibc supplies.
This commit finally (!) makes memcheck behave sanely on ppc32.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4445
to it. Now there are no more offsets and no copying of code into the
stack. We just redirect directly to entry points in m_syscalls.S.
This will mess up pointercheck, since the redirect targets are now in
Valgrind's address space, not the client's. But pointercheck is hosed
anyway, and I'd rather back off to something simple whilst ppc32 is
stabilised. When the address space management stuff is overhauled
then pointercheck may or may not get reinstated, and if it does then
the trampoline stuff will need revisiting.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3977
certain this was the right thing to do, but that stuff sure as hell
didn't fit in any of the existing modules.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3929
