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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14431
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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14419
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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14399
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)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14392
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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14386
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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14384
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).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14374
ppoll argument is called ufds like the poll argument.
Newer architectures (aarch64) implement poll by calling ppoll directly.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14370
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)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14349
glibc is recycling memory for detached threads before a thread
termination => disable the stack cache earlier (i.e. once
a 'non main thread' is seen)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14329
possibly be NULL in several places. Nowadays, VG_(ii_create_image) will
terminate the process if VG_(args_the_exename) is NULL.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14323
pre_mem_read_sockaddr: in the case where the caller doesn't
specify any address family (that is, the family is AF_UNSPEC)
don't perform any further checks on the supplied |sa| address
block, since doing so merely gives rise to false uninitialised
value errors.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14320
Activating this hint using --sim-hints=no-nptl-pthread-stackcache
means the glibc nptl stack cache will be disabled.
Disabling this stack/tls cache avoids helgrind false positive race conditions
errors when using __thread variables.
Note: disabling the stack cache is done by a kludge, dependent on
internal knowledge of glibc code, and using libpthread debug info.
So, this kludge might be broken with newer glibc version.
This has been tested on various platforms and various
glibc versions 2.11, 2.16 and 2.18
To check if the disabling works, you can do:
valgrind --tool=helgrind --sim-hints=no-nptl-pthread-stackcache -d -v ./helgrind/tests/tls_threads |& grep kludge
If you see the below 2 lines, then hopefully the stack cache has been disabled.
--12624-- deactivate nptl pthread stackcache via kludge: found symbol stack_cache_actsize at addr 0x3AF178
--12624:1:sched pthread stack cache size disabling done via kludge
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14313
of clo which are (or should be) 'enum set'.
* pub_tool_options.h : add new macrox VG_USET_CLO and VG_USETX_CLO to
parse an 'enum set' command line option (with or without "all" keyword).
* use VG_USET_CLO for existing enum set clo options:
memcheck --errors-for-leak-kinds, --show-leak-kinds, --leak-check-heuristics
coregrind --vgdb-stop-at
* change --sim-hints and --kernel-variants to enum set
(this allows to detect user typos: currently, a typo in a sim-hint
or kernel variant is silently ignored. Now, an error will be given
to the user)
* The 2 new sets (--sim-hints and --kernel-variants) should not make
use of the 'all' keyword => VG_(parse_enum_set) has a new argument
to enable/disable the use of the "all" keyword.
* The macros defining an 'all enum' set definition was duplicating
all enum values (so addition of a new enum value could easily
give a bug). Removing these macros as they are unused
(to the exception of the leak-kind set).
For this set, the 'all macro' has been replaced by an 'all function',
coded using parse_enum_set parsing the "all" keyword.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14301
* remove useless commented line in hgtls.vgtest
* avoid some #ifdef in arch specific code, hoping to discover more compile
time errors.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14287
To implement QGetTlsAddr, gdbsrv has to know how to get the glibc dtv
address and the module id from the link_map.
These 2 things are dependent on the internals of glibc.
The dependency is mostly isolated in a few lines of arch dependent
code or in an external utility that used a hack + -ldl lib to find
the offset of the modid in the link_map structure.
Tested on x86/amd64/ppc64/s390x. Somewhat tested on ppc32 and arm64.
Untested/a few #ifdef-ed lines not compiled on arm/mips32/mips64
and darwin.
For more background info about thread local storage handling, see
'ELF Handling For Thread-Local Storage' http://www.akkadia.org/drepper/tls.pdf
Changes:
* auxprogs/getoff.c new auxilliary program to get platform specific offsets
(currently only the offset for the module id in struct link_map).
* configure.ac : check for dlinfo(RTLD_DI_TLS_MODID) needed for getoff.c
* new gdbserver_tests/hgtls, testing various types of __thread variables
* various m_gdbserver files:
- implement decoding of the QGetTlsAddr query
- for each platform: platform specific code to get the dtv
- call to external program getoff-<platform> the first time an
__thread variable is printed.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14283
(used for ppc64 platforms) #ifdef-ed and accessed by macros
that becomes NOP on non ppc64 platforms.
This decreases the debuginfo memory by about 2.5 Mb on a big 32 bit application.
Note : doing that, some questions were encountered in the way
tocptr and local_ep have (or do not have) to be copied/maintained
in storage.c canonicaliseSymtab
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14273
around VG_(sysnum_string). Also remove associated macro
VG_SYSNUM_STRING_EXTRA.
The VG_SYSNUM_STRING macro returned a pointer to a variable which
is out of scope. Using that value may cause undefined behaviour.
Change VG_(sysnum_string) to return pointer to static buffer instead.
Fix call sites.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14264
let the compiler handle the ULong to UInt conversion rather than
play with addresses.
Tested manually GDB+vgdb that reading and setting fpsr works, using
code such as (provided by Julian, I cannot write a single line of
arm64 asm :)
void set_fpsr ( uint32_t val ) {
__asm__ __volatile__( "msr fpsr, %0" : : "r"(val) : "cc" );
}
uint32_t get_fpsr ( void ) {
uint32_t res;
__asm__ __volatile__( "mrs %0, fpsr" : "=r"(res) : : "cc" );
return res;
}
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14256
files in the dwarf3 reader.
Basically, the change consists in replacing in the DiInlLoc struct
const HChar* filename; /* caller source filename */
by
UInt fndn_ix; /* index in di->fndnpool of caller source
dirname/filename */
A similar change is done in DiVariable struct, as the
read_filename_Table code is shared between the inline info reader
and the varinfo reader.
Note however that outputting dirname in variable description
is not done. Unclear if that is desired or not.
It should be trivially doable however.
Replacing filename by fndn_ix implies a bunch of semi-mechanical
changes.
The code to read the directory names is in the new function
static
XArray* read_dirname_xa (struct _DebugInfo* di, const HChar *compdir,
Cursor *c,
Bool td3 )
Note that readdwarf.c and readdwarf3.c have significant duplicated
logic. Would be nice to integrate these 2 dwarf readers in one
single reader. This function is directly inspired from
an equivalent piece of code in readdwarf.c.
Modified memcheck/tests/varinfo5.vgtest to test the dirname appears
in the inlined functions.
Impact on memory is neglectable (a few Kb on a big executable).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14245
to add PPC64 LE support. The other two patches can be found in Bugzillas
334384 and 334834. Note, there are no VEX changes in this patch.
PP64 Little Endian test case fixes.
This patch adds new LE and BE expect files where needed. In other
cases, the test was fixed to run correctly on LE and BE using based on
testing to see which platform is being used.
Where practical, the test cases have been changed so that the output
produced for BE and LE will be identical. The test cases that require
a major rewrite to make the output identical for BE and LE simply
had an additional expect file added.
Signed-off-by: Carl Love <carll@us.ibm.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14240
to add PPC64 LE support. The other two patches can be found in Bugzillas
334384 and 334836.
POWER PC, add the functional Little Endian support, patch 2
The IBM POWER processor now supports both Big Endian and Little Endian.
The ABI for Little Endian also changes. Specifically, the function
descriptor is not used, the stack size changed, accessing the TOC
changed. Functions now have a local and a global entry point. Register
r2 contains the TOC for local calls and register r12 contains the TOC
for global calls. This patch makes the functional changes to the
Valgrind tool. The patch makes the changes needed for the
none/tests/ppc32 and none/tests/ppc64 Makefile.am. A number of the
ppc specific tests have Endian dependencies that are not fixed in
this patch. They are fixed in the next patch.
Per Julian's comments renamed coregrind/m_dispatch/dispatch-ppc64-linux.S
to coregrind/m_dispatch/dispatch-ppc64be-linux.S Created new file for LE
coregrind/m_dispatch/dispatch-ppc64le-linux.S. The same was done for
coregrind/m_syswrap/syscall-ppc-linux.S.
Signed-off-by: Carl Love <carll@us.ibm.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14239
to add PPC64 LE support. The other two patches can be found in Bugzillas
334834 and 334836. The commit does not have a VEX commit associated with it.
POWER PC, add initial Little Endian support
The IBM POWER processor now supports both Big Endian and Little Endian.
This patch renames the #defines with the name ppc64 to ppc64be for the BE
specific code. This patch adds the Little Endian #define ppc64le to the
Additionally, a few functions are renamed to remove BE from the name if the
function is used by BE and LE. Functions that are BE specific have BE put
in the name.
The goals of this patch is to make sure #defines, function names and
variables consistently use PPC64/ppc64 if it refers to BE and LE,
PPC64BE/ppc64be if it is specific to BE, PPC64LE/ppc64le if it is LE
specific. The patch does not break the code for PPC64 Big Endian.
The test files memcheck/tests/atomic_incs.c, tests/power_insn_available.c
and tests/power_insn_available.c are also updated to the new #define
definition for PPC64 BE.
Signed-off-by: Carl Love <carll@us.ibm.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14238
