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
If the pre_thread_ll_create tracking function would be invoked without the
big lock being held, that would trigger a race condition in the tools that
implement this tracking function.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12458
--vgdb-error=N is specified, print a bit of text telling the user the
magic commands to give GDB in order to attach to the process.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11822
I tried using 'svn merge' to do the merge but it did a terrible job and
there were bazillions of conflicts. So instead I just took the diff between
the branch and trunk at r10155, applied the diff to the trunk, 'svn add'ed
the added files (no files needed to be 'svn remove'd) and committed.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10156
Split the scheduler initialisation into two phases, for reasons I
can't exactly remember. But I think it was so that the tool can be
told of the initial thread's TID before it is notified of any initial
address range permissions. Or something like that.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7121
and VG_(set_sleeping) to VG_(release_BigLock). And some other minor
renamings to the thread locking stuff, to make it easier to follow.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6408
Minor adjustments to the scheduler, mostly cosmetic.
- rename VG_(kill_thread) to VG_(get_thread_out_of_syscall), which
is what it actually does.
- Remove 'semaphore' terminology in places and use 'lock' instead.
- Give an extra 'HChar* who' arg to VG_(set_running) and
VG_(set_sleeping), which is printed when --trace-sched=yes.
This makes it easier to make sense of lock ownership changes
from the debug output.
- various other improvements to debug printing
- add a kludge to encourage the AIX scheduler to switch threads
more often when more than one is runnable (am not claiming to
understand this); otherwise CPU starvation can appear to happen
- more assertions in sema.c (the pipe-based lock); cycle the token
through 'A' to 'Z' to make strace/truss output more understandable;
fix longstanding bug wherein sema_down() tries to read two bytes
even though sema_up only writes one.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6281
branch hereby becomes inactive. This currently breaks everything
except x86; fixes for amd64/ppc32 to follow.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5520
changes from r4341 through r4787 inclusive). That branch is now dead.
Please do not commit anything else to it.
For the most part the merge was not troublesome. The main areas of
uncertainty are:
- build system: I had to import by hand Makefile.core-AM_CPPFLAGS.am
and include it in a couple of places. Building etc seems to still
work, but I haven't tried building the documentation.
- syscall wrappers: Following analysis by Greg & Nick, a whole lot of
stuff was moved from -generic to -linux after the branch was created.
I think that is satisfactorily glued back together now.
- Regtests: although this appears to work, no .out files appear, which
is strange, and makes it hard to diagnose regtest failures. In
particular memcheck/tests/x86/scalar.stderr.exp remains in a
conflicted state.
- amd64 is broken (slightly), and ppc32 will be unbuildable. I'll
attend to the former shortly.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4789
Removes the dependence of m_scheduler/ on m_main.c; reduces the
dependence of m_signals.c on m_main.c.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3955
- Broke part of m_scheduler off into a new module m_threadstate. It
contains ThreadState, VG_(threads)[] and some basic operations on the
thread table. All simple stuff, the complex stuff stays in m_scheduler.
This avoids lots of circular dependencies between m_scheduler and other
modules.
- Managed to finally remove core.h and tool.h, double hurrah!
- Introduced pub_tool_basics.h and pub_core_basics.h, one of which is
include by every single C file.
- Lots of little cleanups and changes related to the above.
- I even did a small amount of documentation updating.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3944
the m_syscalls module. Fundamentally the aim of the overhaul is to
clean up the logic and abstractions surrounding syscalls in order that
we can cleanly support ppc32 and other new targets. Aims in detail:
* To further decouple the syscall PRE/POST wrappers from specifics of
how those values are stored on a given platform. The wrappers look
the same as they did before, mostly (eg, references to ARGn and
RES are unchanged), but now those macros refer to values in structs
SyscallArgs and SyscallStatus (see priv_types_n_macros.h).
* Complete overhaul of the driver logic for syscalls. The resulting
logic is algorithmically identical to what we had before, but is
more documented, and deals with moving arg/result data between
platform specific representations and the canonical forms in
structs SyscallArgs and SyscallStatus.
* Also as a result of this change, remove problems in the old logic
due to assignments of RES in PRE wrappers trashing the ARGs whilst
we still need to see them.
* Lots of other cleanups and documentation. There is extensive
commentary in syscalls-main.c.
The driver logic has been placed in its own file, syscalls-main.c.
New/deleted files in m_syscalls:
* syscalls.c is divided up into syscalls-main.c, containing driver
logic, and syscalls-generic.c, containing generic Unix wrappers.
* priv_syscalls.h is chopped up into priv_types_n_macros.h
and priv_syscalls-{generic,main}.h.
------------
All the above changes are in m_syscalls. However there is one
system-wide change as a result of all this.
The x86-linux assumption that syscall return values in the range -4095
.. -1 are errors and all others are values, has been done away with
everywhere. Instead there is a new basic type SysRes which holds a
system call result in a platform-neutral way.
Everywhere that previously an Int would have held a system call
result, there is now a SysRes in its place.
------------
Almost everything works on SuSE 9.1 (LinuxThreads) again. NPTL will
still be majorly broken; I will commit fixes shortly. AMD64 is also
totalled. I will get to that too.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3849
number of files that depend on it, but there are still some which should be
removed in the future.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3819
