* print the output 64-bit results in most-to-least-significant
lane format
* change the memory values used in these tests to ones which
are reliably able to detect confusion of 8-bit lanes. The
previous values couldn't to that reliable. This change causes
the diff to be huge because the stdout.exp changes a lot.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13374
it easier to sync with stderr output. Also, add some more helpful
data for testing Neon loads/stores.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13372
Linaro gcc 4.6.3, running on an A9. Not sure why these need to be
updated, but they results are same as native on said platform, so am
not worried.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12660
rev 12001 has introduced a regression in VG_(env_remove_valgrind_env_stuff):
to avoid modifying a possibly read-only env string, the string is duplicated,
and the copy is modified. However, mash_env_column modifies the string
"in-place". The modified string was not put back in the env (and could not,
because the src string is only partially copied).
This means that the valgrind preload strings were not cleaned up and
when a 32 bit executable execs a 64 bits (or vice versa: 64 bit execs 32 bits),
LD_PRELOAD contains both the 32 bits and 64 bits versions of Valgrind
vgpreload.... => ld.so then gives an error msg, as it can't preload either
the 32 or the 64 bits version.
The patch fixes this by duplicating the whole env string, and passing
to mash_colon_env a pointer to the correct offset in the whole env string.
The duplicated string is replacing the original entry in envp.
This patch adds two regression tests : none/tests/allexec32 and
none/tests/allexec64. On a bi-arch valgrind, these will be 32bits and 64 bits
executables, exec-ing each other. On a single arch, one will be a symlink
to the other (to avoid different .exp files, and still test exec).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12287
post-index is bogus due to an accidental stringification in the macro.
Bug 277689. (Mans Rullgard, mans@mansr.com)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11902
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
bit-rotted badly and was clogging up the code.
I put the useful remnants in docs/porting-to-ARM in case anyone ever
wants to try porting to ARM again.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4092
run, though. There are lots of stubs to be filled in. (The asm ones currently
just have "swi" in them, which seems to cause seg faults.)
Also, some of the macros are decided dubious, especially:
ARCH_* are bogus
SYSCALL_RET is bogus
PLATFORM_SET_SYSCALL_RESULT is bogus
not sure about SET_SYSCALL_RETVAL
FIRST_STACK_FRAME et al -- bogus?
VG_MAX_JUMPS ?
And in stage2.lds, the 0x8048000 is almost certainly wrong
This required some tweakings of the core:
- some of the vki_*.h kernel types were fixed up
- had to disable the AM_PROG_CC_C_O macro in configure.in, because automake
(autoconf?) didn't like it...
- some "#ifdef __x86__" guards were introduced, for nasty x86 things I don't
yet know how to factor out (trampoline page muck, sysinfo page muck).
- fixed a minor stupidity in vg_proxylwp.c.
- moved the ptrace wrapper into the x86-linux part
- had to change the intercept mangling scheme, to use 'J' instead of '$' as the
escape char because GCC didn't like '$'. This is all very dubious, and only
works because none of our intercepted symbols contains a 'J'. To be fixed up
ASAP.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3120
