The VG_MIN_MALLOC_SZB was incorrectly defined for MIPS64.
The incorrect value was 8 and the correct value is 16.
Fixes massif/tests/big-alloc for MIPS64.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13455
Reusing parts of Chris Dearman's change in GDB to avoid placing breakpoints
in a branch delay slot.
Fixes gdbserver_tests/mcbreak for MIPS32 and MIPS64.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13451
Another mmap issue in which another VG_(am_get_advisory) needs adjustment
wrapper for cases when (VKI_SHMLBA > VKI_PAGE_SIZE) and argument is
VKI_MAP_SHARED.
Fix by DejanJ for Bug #320057.
Issue and the test case by Vasile Floroiu.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13450
GCC allows incomplete enums as GNU extension.
http://gcc.gnu.org/onlinedocs/gcc/Incomplete-Enums.html
These are marked as DW_AT_declaration and won't have a size.
They can only be used in declaration or as pointer types.
You can't allocate variables or storage using such an enum type.
So don't require a size for such enum types.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13433
exceeds the allowable range. With this change, it should be
essentially impossible to crash V by feeding it invalid ELF or Dwarf.
git-svn-id: svn://svn.valgrind.org/valgrind/branches/DISRV@13432
* add a new flag --allow-mismatched-debuginfo to override the
CRC32/build-id checks, if needed
* tidy up logic for finding files on the --extra-debuginfo-path
and at the --debuginfo-server
* don't assert if connection to the debuginfo server is lost;
instead print a reasonable message and quit.
git-svn-id: svn://svn.valgrind.org/valgrind/branches/DISRV@13431
If the command line option --main-stacksize is not used,
the current ulimit value is used, with a min of 1MB
and a max of 16MB. Document this min/max default formula
in the --help.
Also indicate that Valgrind supports ARMv7
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13426
Add cases for PTRACE_GETREGSET in PRE(sys_ptrace) and POST(sys_ptrace).
This fixes memcheck/tests/linux/getregset on MIPS64 platforms with kernel
that supports ptrace call with PTRACE_GETREGSET.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13418
* Addition of a function to compute size of buffer needed for VG_(mkstemp)
* Use it to dimension buffers for all VG_(mkstemp) calls.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13409
Bug #320116. sockaddr_rc might contain some padding which might not be
initialized. Explicitly check the sockaddr_rc fields are set. That also
produces better diagnostics about which field is unitialized.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13404
Enable wrappers for syscalls prlimit64, process_vm_readv, process_vm_writev,
needed by the following tests:
- none/tests/rlimit64_nofile and
- none/tests/process_vm_readv_writev.
The change also adds definitions for several system calls for MIPS64.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13400
See companion patch VEX r2719.
Patch by Maran Pakkirisamy (maranp@linux.vnet.ibm.com).
Part of fixing BZ #307113
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13387
On Ubuntu systems, ptrace_scoping could forbid a process to ptrace another.
This ptrace scoping was already handled for vgdb by using SET_PTRACER
(the valgrind process must be ptraced by vgdb when it is blocked
in a syscall).
set_ptracer is however also needed when the old mechanism --db-attach=yes
is used.
The following changes are done:
* make the set_ptracer logic callable outside gdbserver
* make set_ptracer less restrictive (i.e. allow all
processes of the user to ptrace). This removes a limitation for vgdb.
* call the set_ptracer in the child launched for --db-attach=yes
* cleaned up the ptrace scope restriction message and doc as vgdb
is now working properly by default, even with ptrace_scope enabled.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13384
sys_get_mempolicy.
This patch add support for the PPC64 sytem calls:
259 - sys_mbind
260 - sys_get_mempolicy
261 - sys_set_mempolicy
This patch also adds the Add syscall 259, sys_mbind, support for the PPC32
platform.
The patch fixes bugzilla 318932.
Signed-off-by: Carl Love <cel@us.ibm.com>
---
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13383
With rev 13368, Valgrind obeys PT_GNU_STACK making the stack not
executable. This makes inferior function call with GDB >= 7.5 failing,
as GDB places a breakpoint on the stack, which must be decoded
and translated by Valgrind to have the inferior function call properly done.
=> introduce a special case in the conditions to allow translation
when a segment is not executable but is readable and there is a
breakpoint at the address.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13381
Restart logic has changed in kernel, this is counterpart in Valgrind.
This change fixes:
none/tests/syscall-restart1
none/tests/syscall-restart2
for mips64.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13379
Reading header length and values in external line info was incorrect at
some places as it used offsets based on dw64 that came from .debug_info.
Instead, offsets should be calculated based on is64 from .debug_line.
This issue surfaced in MIPS64 port, and it was discussed at:
https://bugs.kde.org/show_bug.cgi?id=313267#c20
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13373
Bug #305513. We should only read the first DIE of a compilation unit.
Each compilation unit header is followed by a single DW_TAG_compile_unit
(or DW_TAG_partial_unit, but those aren't important here) and its children.
There is no reason to read any of the children at this point. If the first
DIE isn't a DW_TAG_compile_unit we are done, none of the child DIEs will
provide any useful information.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13369
Bug #305513 contained a patch for some extra robustness checks. But
the real cause of crashing in the read_unitinfo_dwarf2 DWARF reader
seemed to have been this issue where DWARF version 2 DWZ partial_units
were read and DW_FORM_ref_addr had an unexpected size. This combination
is rare. DWARF version 4 is the current default version of GCC.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13367
The replacement functions are running on the simulated CPU.
The code on the simulated CPU does not necessarily use
all arguments. E.g. args can be ignored and/or only given
to a NON SIMD call.
The definedness of such 'unused' arguments will not be verified
by memcheck.
A call to 'trigger_memcheck_error_if_undefined' allows
memcheck to detect such errors for the otherwise unused args.
Apart of allowing memcheck to detect an error, the function
trigger_memcheck_error_if_undefined has no effect and
has a minimal cost for other tools replacing malloc functions.
(suggestion of the 'no operation check' from Julian).
tested on f12/x86, debian6/amd64, f18/ppc64
Note that some Darwin specific code has been modified
in coregrind/m_replace_malloc/vg_replace_malloc.c.
(Some of) this code has not been compiled (no access to a
Darwin system). The code changed is trivial, so there is
some chance it will compile and even maybe work.
Added a new test verifying that various malloc related
functions undefined args are triggering an error in memcheck.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13361
Enable wrappers on mips64 for the following calls:
- dup3
- accept4
- epoll_create1
- timerfd_settime
- newfstatat
Also, allow additional flock64 values in sys_fcntl for mips64.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13358
* when SEGV trapped, report the main thread size as an unsigned size_t
* Similar for memcheck overlap errors
For example, for the 2 calls:
memcpy(&a, &a, 2147483648UL);
memcpy(&a, &a, -1); // silently accepted by gcc 4.4.4 -Wall
// while the 3rd arg is supposed to be a size_t
we now obtain (on a 32 bit system)
Source and destination overlap in memcpy(0xbe97113f, 0xbe97113f, 2147483648)
Source and destination overlap in memcpy(0xbef6d13f, 0xbef6d13f, 4294967295)
instead of
Source and destination overlap in memcpy(0xbe8e012f, 0xbe8e012f, -2147483648)
Source and destination overlap in memcpy(0xbe8e012f, 0xbe8e012f, -1)
Do not ask me why
memcpy(&a, &a, -1);
is supposed to be accepted/acceptable/valid code.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13326
The call to VG_(gdbserver_report_signal) is ignored
in synth_fault_common (m_signals.c) as these signals
are always to be delivered (as explained by the following
comment).
=> better document that the return value is ignored on purpose.
(spotted by Florian, using Coverity)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13306
