* All Linux targets: add minimal ioctl support for the ION_IOC family
* Android targets: change proprietary-ioctl support for GPUs from
being a build-time #define kludge to being controlled by --kernel-variant,
as it should be. Update documentation accordingly.
gcc on arm64 -Og produces a (false positive) warning that
stackPos might be used uninitialised.
Silence gcc by assigning a value to stackPos.
This value must be overriden if a stack description is found.
The fact that the value is overriden is asserted.
Update helgrind default suppression so that it matches with
both --read-inline-info=yes or =no
Some piece of code in glibc produces an error to be suppressed
with default helgrind supp file.
The stacktrace with inline info is:
==14392== Possible data race during write of size 1 at 0x5BB36A7 by thread #1
==14392== Locks held: none
==14392== at 0x4C2B3B5: mempcpy (vg_replace_strmem.c:1354)
==14392== by 0x40107FD: _dl_allocate_tls_init (dl-tls.c:437)
==14392== by 0x4E3BF0F: get_cached_stack (allocatestack.c:250)
==14392== by 0x4E3BF0F: allocate_stack (allocatestack.c:486)
==14392== by 0x4E3BF0F: pthread_create@@GLIBC_2.2.5 (pthread_create.c:460)
==14392== by 0x4C3039C: pthread_create_WRK (hg_intercepts.c:270)
==14392== by 0x4C304AB: pthread_create@* (hg_intercepts.c:301)
==14392== by 0x400926: main (tc22_exit_w_lock.c:42)
stack trace without inline info:
==5432== at 0x4C2B3B5: mempcpy (vg_replace_strmem.c:1354)
==5432== by 0x40107FD: _dl_allocate_tls_init (dl-tls.c:437)
==5432== by 0x4E3BF0F: pthread_create@@GLIBC_2.2.5 (allocatestack.c:250)
==5432== by 0x4C3039C: pthread_create_WRK (hg_intercepts.c:270)
==5432== by 0x4C304AB: pthread_create@* (hg_intercepts.c:301)
==5432== by 0x400926: main (tc22_exit_w_lock.c:42)
The suppression supposed to match the above is:
{
helgrind---_dl_allocate_tls
Helgrind:Race
fun:mempcpy
fun:_dl_allocate_tls_init
fun:pthread_create@@GLIBC_2.2*
fun:pthread_create_WRK
fun:pthread_create@*
}
This only matches the 2nd stack trace, does not match the one
with inline info.
2 solutions:
* only match the last top 2 fun, i.e. a suppression such as:
{
helgrind---_dl_allocate_tls
Helgrind:Race
fun:mempcpy
fun:_dl_allocate_tls_init
}
Or alternatively use ...
{
helgrind---_dl_allocate_tls
Helgrind:Race
fun:mempcpy
fun:_dl_allocate_tls_init
...
fun:pthread_create@@GLIBC_2.2*
fun:pthread_create_WRK
fun:pthread_create@*
}
As helgrind suppressions are usually precise and/or use ...,
this last approach chosen
The 4th parameter of lzo1x_decompress_safe has lzo_uint * type
which, despite the name, is a pointer to an unsigned long.
So we should be passing arguments of matching type.
Spotted by the Coverity checker.
Mark Wielaard [Tue, 2 Sep 2014 10:16:42 +0000 (10:16 +0000)]
Tweak gdbserver_tests/mcinfcallWSRU.stderrB.exp to match more gdb versions.
Some gdb versions don't show the source line:number after switching
threads in #0 0x........ in do_burn (). Filter "at line:number" out
and don't expect it.
prepare for changing the default of --read-inline-info
suppvarinfo5 is using suppression entries that explicitely checks
for a stack trace without inline info.
So, indicate to not read the inline info.
This also means we will have (and keep) at least one test testing the
behaviour of --read-inline-info=no
Prepare to change the default for --read-inline-info from =no to =yes
The interception/replacements functions should preferrably not
depend on the value of --read-inline-info.
The idea is to change the default from no to yes.
Depending on the no or yes, some intercept/replacement functions
that are inlined will be shown or not shown in stacktraces.
To have such stack traces not depending on the value of --read-inline-info,
such functions should either be marked as
noinline
or be defined as macros.
Rename a bunch of __unused fields to __unused0, since some Android
NDK's appear to #define __unused to __attribute__((__unused__)),
causing the build to fail in bizarre ways.
Remove two extraneous Ls introduced by mistake in r14319, which had
the effect of causing CFLAGS environment variable settings to be
ignored for certain parts of the build (genoffsets.c, for one).
Mark Wielaard [Mon, 1 Sep 2014 15:29:55 +0000 (15:29 +0000)]
Bug 338703 helgrind on arm-linux gets false positives in dynamic loader.
There are a couple of issues with helgrind on arm-linux with glibc:
- Thread creation stack traces cannot unwind through clone
(cfi ends right after syscall)
- ld.so has a special "hard float" name that isn't recognized as special
(ld-linux-armhf.so.3)
- Races are found when manipulating GOT sections.
Improve description of an address that is on a stack but below sp.
An address below the sp will be described as being on a stack, but below sp.
The stack for such an address is found in the registered stacks.
Also, if there is a guard page at the end of the stack (lowest address)
an address in this page will be described as being in thread guard page.
A guard page is recognised as being a page not readable/writable/executable.
Mark Wielaard [Sat, 30 Aug 2014 20:37:40 +0000 (20:37 +0000)]
Bug 338681 Enable clone backtrace hack for i386-linux in helgrind.
glibc doesn't provide CFI unwind information right after the clone call
(because it would be invalid in the child). Enable the same workaround
for i386-linux that is already used for amd64-linux (subtract 3 from ip).
Julian Seward [Sat, 30 Aug 2014 19:21:48 +0000 (19:21 +0000)]
Helgrind needs to know the soname of ld.so, and on arm64-linux
it is different (ld-linux-aarch64.so.1) from all other targets.
(Why?) This makes Helgrind at least somewhat usable on arm64-linux.
The semantic of the stack bounds is not consistent or is not described.
At various places, there were either some assumption that the 'end'
boundary (highest address) was either not included, included,
or was the highest addressable word, or the highest addressable byte.
This e.g. was very visible when doing:
./vg-in-place -d -d ./helgrind/tests/tc01_simple_race|&grep regi
giving
--24040:2:stacks register 0xBEDB4000-0xBEDB4FFF as stack 0
--24040:2:stacks register 0x402C000-0x4A2C000 as stack 1
showing that the main stack end was (on x86) not the highest word
but the highest byte, while for the thread 1, the registered end
was a byte not part of the stack.
The attached patch ensures that stack bounds semantic are documented and
consistent. Also, some of the stack handling code is factorised.
The convention that the patch ensures and documents is:
start is the lowest addressable byte, end is the highest addressable byte.
(the words 'min' and 'max' have been kept when already used, as this wording is
consistent with the new semantic of start/end).
In various debug log, used brackets [ and ] to make clear that
both bounds are included.
The code to guess and register the client stack was duplicated
in all the platform specific syswrap-<plat>-<os>.c files.
Code has been factorised in syswrap-generic.c
The patch has been regression tested on
x86, amd64, ppc32/64, s390x.
It has been compiled and one test run on arm64.
Not compiled/not tested on darwin, android, mips32/64, arm
More in details, the patch does the following:
coregrind/pub_core_aspacemgr.h
include/valgrind.h
include/pub_tool_machine.h
coregrind/pub_core_scheduler.h
coregrind/pub_core_stacks.h
- document start/end semantic in various functions
also in pub_tool_machine.h:
- replaces unclear 'bottommost address' by 'lowest address'
(unclear as stack bottom is or at least can be interpreted as
the 'functional' bottom of the stack, which is the highest
address for 'stack growing downwards').
coregrind/pub_core_initimg.h
replace unclear clstack_top by clstack_end
coregrind/m_main.c
updated to clstack_end
coregrind/pub_core_threadstate.h
renamed client_stack_highest_word to client_stack_highest_byte
coregrind/m_scheduler/scheduler.c
computes client_stack_highest_byte as the highest addressable byte
Update comments in call to VG_(show_sched_status)
coregrind/m_machine.c
coregrind/m_stacktrace.c
updated to client_stack_highest_byte, and switched
stack_lowest/highest_word to stack_lowest/highest_byte accordingly
coregrind/m_stacks.c
clarify semantic of start/end,
added a comment to indicate why we invert start/end in register call
(note that the code find_stack_by_addr was already assuming that
end was included as the checks were doing e.g.
sp >= i->start && sp <= i->end
coregrind/pub_core_clientstate.h
coregrind/m_clientstate.c
renames Addr VG_(clstk_base) to Addr VG_(clstk_start_base)
(start to indicate it is the lowest address, base suffix kept
to indicate it is the initial lowest address).
coregrind/m_initimg/initimg-darwin.c
updated to VG_(clstk_start_base)
replace unclear iicii.clstack_top by iicii.clstack_end
updated clstack_max_size computation according to both bounds included.
coregrind/m_initimg/initimg-linux.c
updated to VG_(clstk_start_base)
updated VG_(clstk_end) computation according to both bounds included.
replace unclear iicii.clstack_top by iicii.clstack_end
coregrind/pub_core_aspacemgr.h
extern Addr VG_(am_startup) : clarify semantic of the returned value
coregrind/m_aspacemgr/aspacemgr-linux.c
removed a copy of a comment that was already in pub_core_aspacemgr.h
(avoid double maintenance)
renamed unclear suggested_clstack_top to suggested_clstack_end
(note that here, it looks like suggested_clstack_top was already
the last addressable byte)
* factorisation of the stack guessing and registration causes
mechanical changes in the following files:
coregrind/m_syswrap/syswrap-ppc64-linux.c
coregrind/m_syswrap/syswrap-x86-darwin.c
coregrind/m_syswrap/syswrap-amd64-linux.c
coregrind/m_syswrap/syswrap-arm-linux.c
coregrind/m_syswrap/syswrap-generic.c
coregrind/m_syswrap/syswrap-mips64-linux.c
coregrind/m_syswrap/syswrap-ppc32-linux.c
coregrind/m_syswrap/syswrap-amd64-darwin.c
coregrind/m_syswrap/syswrap-mips32-linux.c
coregrind/m_syswrap/priv_syswrap-generic.h
coregrind/m_syswrap/syswrap-x86-linux.c
coregrind/m_syswrap/syswrap-s390x-linux.c
coregrind/m_syswrap/syswrap-darwin.c
coregrind/m_syswrap/syswrap-arm64-linux.c
Some files to look at more in details:
syswrap-darwin.c : the handling of sysctl(kern.usrstack) looked
buggy to me, and has probably be made correct by the fact that
VG_(clstk_end) is now the last addressable byte. However,unsure
about this, as I could not find any documentation about
sysctl(kern.usrstack). I only find several occurences on the web,
showing that the result of this is page aligned, which I guess
means it must be 1+ the last addressable byte.
syswrap-x86-darwin.c and syswrap-amd64-darwin.c
I suspect the code that was computing client_stack_highest_word
was wrong, and the patch makes it correct.
syswrap-mips64-linux.c
not sure what to do for this code. This is the only code
that was guessing the stack differently from others.
Kept (almost) untouched. To be discussed with mips maintainers.
coregrind/pub_core_libcassert.h
coregrind/m_libcassert.c
* void VG_(show_sched_status):
renamed Bool valgrind_stack_usage to Bool stack_usage
if stack_usage, shows both the valgrind stack usage and
the client stack boundaries
coregrind/m_scheduler/scheduler.c
coregrind/m_gdbserver/server.c
coregrind/m_gdbserver/remote-utils.c
Updated comments in callers to VG_(show_sched_status)
Julian Seward [Fri, 29 Aug 2014 19:12:38 +0000 (19:12 +0000)]
run_thread_for_a_while: Make the computation of done_this_time less
bogus, and in particular ensure that it can't be zero if in fact the
thread did do some useful work. Fix up a couple of associated
assertions. Fixes #336435.
Mark Wielaard [Fri, 29 Aug 2014 14:28:30 +0000 (14:28 +0000)]
Use getdents64 syscall on linux.
getdents has been deprecated since linux 2.4 and newer arches (arm64)
might no longer provide the getdents syscall. Use getdents64 for reading
the /proc/self/fd/ dir so --track-fds=yes works reliable on all arches.
Without this the none/tests/fdleak*vgtest might fail.
Fix a bunch of defined(VGA_ppc64)
(a.o. this was making leak_cpp_interior test failing,
as the ppc64 specific code in mc_leakcheck.c was not compiled in)
Mark Wielaard [Thu, 28 Aug 2014 14:59:04 +0000 (14:59 +0000)]
Bug 338615 suppress glibc 2.20 optimized strcmp implementation for ARMv7.
Add an add_hardwired_spec for strcmp in VG_(redir_initialise) for
ld-linux.so.3 and ld-linux-armhf.so.3 to use a simple strcmp
implementation in m_trampoline.S (compiled from the trivial .c code
to asm with gcc like the other implementations in that file).
338499 --sim-hints parsing broken due to wrong order in tokens (after introduction of no-nptl-pthread-stackcache)
Fix the token order in m_main.c
Somewhat retested by running the regression tests
(testing no-nptl-pthread-stackcache) and testing in an outer/inner setup
(testing enable-outer,no-inner-prefix).
It seems there is no regtest for the 2 other flags (lax-ioctls,fuse-compatible)
projects / thirdparty / valgrind.git / log
