update callgrind and cachegrind filtering logic following rev 14469
rev 14469 gives better description of the tweak done to the
simulated cache. Update filtering logic to filter this (variable) tweaking
msg.
Mark Wielaard [Sat, 6 Sep 2014 19:29:51 +0000 (19:29 +0000)]
readstabs.c: Don't include a.out.h, just define the stabs symbol nlist entry.
readstabs.c tries to include a.out.h to get the stabs symbol list entry
definition. STABS isn't specifically tied to the a.out format though.
The symbol entry structure just happens to be defined in the a.out.h
header. The header isn't really standard though. It might be provided
by glibc or the kernel in different locations. And not all arches support
the a.out format so the header might not even exist. Just define the
needed nlist struct entry directly in readstabs.c for VGO_linux. All
arches in glibc and the kernel use the same one anyway.
Mark Wielaard [Sat, 6 Sep 2014 17:37:55 +0000 (17:37 +0000)]
nightly: Try harder to get vendor stuff.
/etc/issue.net might just contain control chars (like \S) a generic welcome
message or omit the precise version. The newest standard is /etc/os-release
http://www.freedesktop.org/software/systemd/man/os-release.html
Otherwise there is often lsb_release
http://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/lsbrelease.html
Try those first, fall back to /etc/issue.net if neither is there.
drd: Make regression test output independent of --read-inline-info
There are plans to enable --read-inline-info=yes for all Valgrind
tools. Hence make the DRD regression test output independent of how
--read-inline-info has been set.
Partial bypass for 338803 Handling of dwz debug alt files or cross-CU is broken
This patch avoids dereferencing absori that are in other CUs than
the CU currently being read.
This avoids dwarf reading errors when reading inlined information.
The bypass results in inlined function being reported as
UnknownInlinedFun rather than the real correct function name.
--read-var-info=yes is still broken for unknown reasons
(probably type reading is doing some other cross-CU references ?).
Mark Wielaard [Fri, 5 Sep 2014 22:50:51 +0000 (22:50 +0000)]
Always check crc in open_debug_file for now. Bug #338791 followup.
Revision r14464 made it so that debug alt files could be found by their
build-id or their (relative) file path. Debug alt files are matched using
the given build-id, but by crc. Calculating the full CRC is costly, but
currently still needed to avoid misidentifying the main file as debug
file. Slightly more efficient would be to use fstat to check we aren't
actually opening the main file under any other name (but that only works
for local DiImages). Or we could check that the file being opened actually
has at least one .debug* section. But this change was the minimal patch
to make things work as before.
Be more careful to separate build flags for the preload shared objects
as opposed to the valgrind code proper. In particular, make sure that
-mpreferred-stack-boundary=2 does not get used for the preload shared
objects, since that can cause the stack to become misaligned and leads
to segfaults. Modified version of a patch from Matthias Schwarzott
(zzam@gentoo.org). Fixes #324050.
Also, fix the configure check in configure.ac for
-mpreferred-stack-boundary=2 so that it checks whether this is
allowable for 32-bit code generation even on 64-bit (x86) hosts. This
check was wrong before now and led to 32-bit builds on 64-bit hosts
generating poorer code for speed critical helper functions (eg
helperc_LOADV32le) than on 32-bit builds on 32-bit hosts.
maybe_tweak_LLc: generalise this so that it can mash more or less any
cache size and associativity pair into something the simulator can
actually handle, by increasing the associativity whilst reducing the
number of sets, so that the number of sets becomes a power of two.
Fixes #333501.
Carl Love [Fri, 5 Sep 2014 18:05:24 +0000 (18:05 +0000)]
The update fixes a format issue in the PPC test
none/tests/ppc32/jm-insns.c and none/tests/ppc64/jm-insns.c.
The BE and LE output expect files are updated as well.
There is no Bugzilla related to this update. The issue
was found and the initial patch and BE output update
was done by Florian Krohm <florian@eich-krohm.de>.
Carl Love <cel@us.ibm.com> added the LE output update.
Mark Wielaard [Fri, 5 Sep 2014 14:25:17 +0000 (14:25 +0000)]
Bug 338791 Handle debug alt dwz files that are relative to the debug file.
readdwarf3 would only look for alt dwz files using the build-id.
But alt files can be installed relative to the debug (or main) file.
Fix find_debug_file to allow searching of relative files even if
we don't want an ET_REL (rel_ok) file, and pass the build-id to
open_debug_file so it can be checked. Add the debug file path to
_DebugInfoFSM and set it in find_debug_file once opened. Pass the
dbgname or filename as relative file to resolve an altfile in
read_elf_debug_info when we ahava an debugaltlink_escn.
* 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)
projects / thirdparty / valgrind.git / log
