make their role clearer and their behaviour more consistent with the fields
describing the client's stack. Also made the code in x86-linux/syscalls.c
and amd64-linux/syscalls.c more word-size-independent, which is not strictly
necessary but makes the code similarities between the two files more
obvious.
One consequence of this is that Valgrind's stack on AMD64 is now 16384 * 8
bytes, rather than 16384 * 4 bytes.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3520
greater than MIN_LINE_SIZE equal to MIN_LINE_SIZE. This makes the
x86/fpu-28-108 regression test pass.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3518
- removed "stack_base" which wasn't used in any meaningful way
- added "client_" prefix to make it clear they concern the client's stack
- renamed "stack_size" as "client_stack_szB" to make the units clear
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3516
command-line flag (--max-stackframe=number), rather than hardwiring it
to 2000000. This is helpful for dealing with unruly Fortran programs
which want to allocate large arrays on the stack.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3512
idea is the same -- write functions with special names encoding
sonames and fn names, and have the redir mechanism notice them.
However the way the functions are generated is significantly changed:
* The name mangling scheme has been replaced with one which is just about
simple enough not to need a preprocessing phase. Hence
vg_replace_malloc.c.base is replaced by vg_replace_malloc.c, and
the preprocessor disappears. The demangler in vg_symtab2.c changes
accordingly.
* Kill off the horrendous LIBALIAS macro. In return we have to
enumerate all the redirections longhand, but this is not a big deal.
* Remove use of the GNUisms "attribute alias" and "attribute
protected".
* Remove the hardwired assumption that any C++ new/new[]/etc symbols
we might want to intercept are mangled in GNU style.
* Add more comments.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3510
seemed to completely confuse the compiler and it was generating
nonsense code to get the address of the replacement routines.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3495
don't put a dependency between the install target and $(BUILT_SOURCES)
so doing a straight install doesn't work.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3494
long sequences of x86 insns with IR optimisation disabled, so the
tag-checking crap doesn't get knocked out like it usually does.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3492
steps fails instead of carrying on with the other steps - this should
help ensure that the log fragment sent out contains useful information.
A second change is to ensure that if the regression tests complete
then the full results are included in the email - if they don't
complete then just the last 20 lines of output are sent as before.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3491
VG_(tdict). Also make the typing more meaningful in vg_mallocfuncs_info.
And (barely) start removing the use of "TL_" names in the core.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3488
lot to one. This required two basic changes.
1. Tools are responsible for telling the tool about any functions they
provide that the tool may call. This includes basic functions like
TL_(instrument)(), functions that assist core services such as
TL_(pp_Error)(), and malloc-replacement-related functions like
TL_(malloc)().
2. Tools that replace malloc now specify the size of the heap block redzones
through an arg to the VG_(malloc_funcs)() function, rather than with a
variable VG_(vg_malloc_redzone_szB).
One consequence of these changes is that VG_(tool_init_dlsym)() no longer
needs to be generated by gen_toolint.pl.
There are a number of further improvements that could follow on from this one.
- Avoid the confusingly different definitions of the TL_() macro in the
core vs. for tools. Indeed, the functions provided by the tools now don't
need to use the TL_() macro at all, as they can have arbitrary names.
- Remove a lot of the auto-generated stuff in vg_toolint.c and vg_toolint.h
(indeed, it might be possible to not auto-generate these at all, which
would be nice).
- The handling of VgToolInterface is currently split across vg_needs.c and
vg_toolint.c, which isn't nice.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3487
at system-build time: OFFSET_amd64_RIP. This saves an instruction on
the fast path, and reduces the number of PIE-difficulties by one.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3483
add VG_(has_cpuid) as well. These are then used in place of the inline
assembly in state.c as the compiler was having trouble allocating the
required registers when building in PIE mode.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3476
