History log of /external/valgrind/coregrind/m_initimg/initimg-linux.c
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
c42f255524f0bf498e4c46644c60a4cbda3b7997 28-May-2015 Dmitriy Ivanov <dimitry@google.com> Fix x86_64 target build

Bug: http://b/21471495
Bug: https://bugs.kde.org/id=348342
Change-Id: I5b48491d18ced37c9ecff60661fb4a5b47519219
(cherry picked from commit 22bcca76a224404fa81fff26437d15f17be56fd4)
/external/valgrind/coregrind/m_initimg/initimg-linux.c
3b91f1779802a17344e1901f3b7c0271a22d3194 19-May-2015 carll <carll@a5019735-40e9-0310-863c-91ae7b9d1cf9> Fix for the HWCAP2 aux vector.

The support assumed that if HWCAP2 is present that the system also supports
ISA2.07. That assumption is not correct as we have found a few systems (OS)
where the HWCAP2 entry is present but the ISA2.07 bit is not set. This patch
fixes the assertion test to specifically check the ISA2.07 support bit setting
in the HWCAP2 and vex_archinfo->hwcaps variable. The setting for the
ISA2.07 support must be the same in both variables if the HWCAP2 entry exists.

This patch updates Vagrind bugzilla 345695.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15257 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
75712710b9c49eedcf4f9caa7d7e17494ac3acf8 30-Apr-2015 florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> Remove a few embarassing comments.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15169 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
9dc31561106f3f1b8057fdcdef94fa735a5f9c0a 28-Apr-2015 florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> Use error exit code when bailing out.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15153 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
737548c7409e5d46b72a914ae1dc6d1a48199d25 27-Apr-2015 florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> Remove magic constant. Use LibVEX_GUEST_STATE_ALIGN instead.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15148 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
ca92cdf0c66b8fac8ddfc0c16017329bb9a2d41c 27-Apr-2015 florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> Follow up on VEX r3144 and remove VexGuestTILEGXStateAlignment.
Also fix the alignment check which should be mod 16 not mod 8.
Well, actually, it should be mod LibVEX_GUEST_STATE_ALIGN but
that is another patch.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15147 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
81de065f33b4fbcb02a9a5b7fd75fdb6bde1506f 25-Apr-2015 florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> Fix BZ #342683. Based on patch by Ivo Raisr.
What this does is to make sure that the initial client data segment
is marked as unaddressable. This is consistent with the behaviour of
brk when the data segment is shrunk. The "freed" memory is marked
as unaddressable.
Special tweaks were needed for s390 which was returning early from
the funtion to avoid sloppy register definedness initialisation.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15144 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
112711afefcfcd43680c7c4aa8d38ef180e8811e 10-Apr-2015 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Add a port to Linux/TileGx. Zhi-Gang Liu (zliu@tilera.com)
Valgrind aspects, to match vex r3124.

See bug 339778 - Linux/TileGx platform support to Valgrind



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15080 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
52b284b2fb907204dfae5a067e83eed98ea72dd2 09-Apr-2015 carll <carll@a5019735-40e9-0310-863c-91ae7b9d1cf9> ADD AT_DCACHEBSIZE and AT_HWCAP2 support for POWER PC

Valgrind currently does not support the following AUX vector entries:
AT_DCACHEBSIZE, and AT_HWCAP2. By default these entries are suppressed by
Valgrind. The attached patch adds the needed support so the user level programs
can correctly determine that hardware level they are running on. Specifically
that the ISA 2.07 for Power 8 is supported.

Bugzilla 345695

This fix adds the needed support. It makes a minor change to allow the
VEX settings of the host platform to be passed down so they can be checked
against the HWCAP values.

The files touched are:
coregrind/m_initimg/initimg-linux.c
coregrind/pub_core_initimg.h
coregrind/m_main.c

committed by Carl Love cel@us.ibm.com


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15078 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
26ed419d60369d0545510eba0832566e24452e1e 04-Nov-2014 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Adds initial support for AArch64 (arm64) on Android. Small programs
(/system/bin/ls, /system/bin/date) run. Still to do:

* enable more malloc/free intercepts

* enable wrappers for ashmem and binder syscalls

* check to see if any special ioctl support is required for ARM Mali GPUs



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14690 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
68790a73bcb290746a5b34c44538c3b2728eaaec 13-Sep-2014 florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> VG_(malloc/calloc/strdup) never return NULL (and never will).
So it's pointless to test or assert their return values.
Remove code doing so.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14528 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
38a74d2cc4670e3eb559adff51a376cd6ec98005 30-Aug-2014 philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> 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)



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14392 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
b16609bf952bf381154cb6cba87efc99c2c86a23 20-Aug-2014 florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> Clean up confusion about VG_(args_the_exename) which was believed to
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 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
582d58245637ab05272d89fb94b12fd0f18fa0f8 08-Aug-2014 carll <carll@a5019735-40e9-0310-863c-91ae7b9d1cf9> This commit is for Bugzilla 334834. The Bugzilla contains patch 2 of 3
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 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
cae0cc22b83ffb260ee8379e92099c5a701944cb 08-Aug-2014 carll <carll@a5019735-40e9-0310-863c-91ae7b9d1cf9> This commit is for Bugzilla 334384. The Bugzilla contains patch 1 of 3
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 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
7e5a9c29450b41cba63ac04b9c027d3b97b367ec 24-Feb-2014 cborntra <cborntra@a5019735-40e9-0310-863c-91ae7b9d1cf9> This fixes the shadow validity setup of SP,IA and FPC. The current
code misses a char * cast and thus uses a wrong pointer for memset.
This resulted in corruptions of a thread state for multi threaded
programs. After vex: r2818 the memset did overwrite the tid value
of a thread, making this bug visible.
Lets use the c structures instead of pointer arithmetics.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13838 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
0345188cc1524a809b8d7fe8785e1da098d9cbe4 15-Jan-2014 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> arm64: rename guest_SP to guest_XSP so as to avoid a name clash with
guest_SP from s390 world.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13776 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
f0c1250e324f6684757c6a15545366447ef1d64f 12-Jan-2014 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Add support for ARMv8 AArch64 (the 64 bit ARM instruction set).


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13770 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
3d24135101d712a59f9ec722e95d2a5670ea735e 07-Jan-2014 tom <tom@a5019735-40e9-0310-863c-91ae7b9d1cf9> The value of AT_BASE should be the offset between where the ELF interpreter
expected to be loaded (as expressed in the ELF headers) and where it was
actually loaded, and not (as valgrind was doing) the absolute value of the
load address for the interpreter.

Note that when prelink is not in use the two are normally the same, as the
intpreter (like all shared libraries) is normally linked with a zero load
address. When prelinked that is no longer true.

With that fixed, the hack to patch out AT_BASE to avoid confusing gdb on
systems where prelink is in use is no longer needed.

Fixes BZ#329612


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13768 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
9c6b05db45362b1afb981aa8298ab12ab4027b1a 27-Dec-2013 dejanj <dejanj@a5019735-40e9-0310-863c-91ae7b9d1cf9> mips32: Adding mips32/Android support to Valgrind.

Necessary changes to Valgrind to support mips32 on Android.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13767 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
0f157ddb404bcde7815a1c5bf2d7e41c114f3d73 18-Oct-2013 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Update copyright dates (20XY-2012 ==> 20XY-2013)


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13658 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
1a59a921dbfe75f7535d9dff6b76ea43a5ed961a 11-Sep-2013 florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> Clarify wording.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13541 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
353d8b829ea1a63c17d94388b1473e5b140e5ba8 03-Aug-2013 florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> Followup to the renaming in VEX r2735.
Also ignore AT_DCACHEBSIZE entries in the auxiliary vector as they
are not needed.
Fixes BZ 306587.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13481 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
4fa3d371f8a70bb89e7f6bdf95011c05b3dbc7d4 21-Jul-2013 philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> fix 321960 pthread_create() then alloca() causing invalid stack write errors

Problem created by a discrepancy between the initial main stack
anon segment, and the main stack registered in m_stacks.c

Looking at some tracing; we see that there are two pages of stack:
--9078:2:main tell tool about 0ffefff000-0fff000fff rw-
The stack between the base and the current sp is marked as not accessible:
--9078:2:main mark stack inaccessible 0ffefff000-0fff0004bf

This is matching the aspacemgr view:
--9078:1:aspacem 22: RSVN 0ffe801000-0ffeffefff 8380416 ----- SmUpper
--9078:1:aspacem 23: anon 0ffefff000-0fff000fff 8192 rw---
(all the above is normal/as expected)


However, the main stack is registered in m_stacks.c as having only one page:
--9078:2:stacks register 0xFFF000000-0xFFF000FFF as stack 0

When the main stack is grown, m_stacks.c is informed by m_signals.c
that the stack is grown. This is done by trapping the signal 11
when a not mapped page is accessed.
However, the 2nd page does not cause a signal (as it is mapped).
So, m_stacks.c still believes the main has one page stack.
This then gives problems in the tracking of the SP and current_stack
in m_stacks.c.

Only one page was registered for the main stack, as the registration
was done with values computed before possibly adding a page
needed for the ABI redzone.

The fix is to properly register the main stack with the size of
the stack segment, once all aspects have been taken into account.
With the fix, the stack is registered as:
--31501:2:stacks register 0xFFEFFF000-0xFFF000FFF as stack 0

Another possible fix would be to always register the main stack with the
full size of the aspacemgr stack segment (i.e. the anon+RSVN above)
(idea is that this is similar to non main threads, for which the
full thread stack is registered from the beginning, even if not fully
used yet).
The first fix was preferred, assuming it is better to keep registering
the main stack "physical" size (and not its maximal size).


Test memcheck/tests/thread_alloca added, based on reproducer
done by Daniel Stodden.
The bug might be triggered or not depending on the initial value
of the SP, which is influenced by the size of the "env".
So, the test execs itself, growing each time the environment.
This has given a reasonable chance/way to reproduce the bug on Ubuntu 12
and on a Debian 6.
(tested on amd64/Ubuntu 12 and Debian 6
x86/fedora12
ppc64/fedora18

Note that while investigating this bug, another strange thing was seen:
thread stacks are registered in m_stacks.c but are never unregistered.
It is not very clear that it is needed or not to unregister them:
thread stack segments are not freed when a thread terminates :
when a thread slot is re-used, its thread stack will also be re-used.
(Is that good for address space mgt ? A process that has created many
temporary threads will have the thread stacks lost forever ???).





git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13467 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
50d6d212fc8dfe63e2e83169fd8e12cf72ccfd1a 17-Apr-2013 tom <tom@a5019735-40e9-0310-863c-91ae7b9d1cf9> Pay attention to PT_GNU_STACK when deciding what permissions to
use for the client stack.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13368 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
4df0bfc0614379192c780c944415dc420d9cfe8e 28-Feb-2013 petarj <petarj@a5019735-40e9-0310-863c-91ae7b9d1cf9> mips: adding MIPS64LE support to Valgrind

Necessary changes to Valgrind to support MIPS64LE on Linux.
Minor cleanup/style changes embedded in the patch as well.
The change corresponds to r2687 in VEX.
Patch written by Dejan Jevtic and Petar Jovanovic.

More information about this issue:
https://bugs.kde.org/show_bug.cgi?id=313267


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13292 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
19f91bbaedb4caef8a60ce94b0f507193cc0bc10 10-Nov-2012 florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> Fix more Char/HChar mixups. Closing in...


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13119 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
5d5f0708cf0f57987977fe6330ea91d593c8edc8 06-Nov-2012 philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> fix n-i-bz same as 303624 (fixed in 3.8.0), but for x86 android

(note: this might be a candidate if a 3.8.2 is done).



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13105 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
c8b821428c9a8e63a6d055211963eae6eccc41c0 03-Nov-2012 florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> Fix Char/HChar mixups and constness in m_initimg.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13102 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
03f8d3fc25f5a45c5826259d1b33b7f310117279 05-Aug-2012 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Update copyright dates to include 2012.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12843 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
5d5dd8e6b7ff782fc89f5b96cecf04839742882b 05-Aug-2012 philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> 301265 - add x86 support to Android build

Patch by Dragos Tatulea.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12835 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
77c11850076a05b003d69b72b73b048aae8c4767 19-Jul-2012 philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> Fix 303624 segmentation fault on Android 4.1 (e.g. on android emulator or Galaxy Nexus OMAP)

Valgrind was crashing systematically on Android 4.1.
This crash is caused by AT_IGNORE-ing AT_BASE.
This AT_IGNORE was needed to have breakpoints in shared libs
be handled properly (not very clear what is the problem
in the interaction between Valgrind GDBSERVER, AT_BASE and GDB).
Waiting to better understand all this, as a temporary bypass,
this patch ensures we do not ignore the AT_BASE on android.

The possible consequence is that breakpoints might be inserted
by the Valgrind gdbserver at wrong addresses in shared lib.
(any feedback on that is welcome).

Valgrind was build and then "proved" to work on Android emulator 4.0
and emulator 4.1, by using memcheck on one executable.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12758 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
eeb0733e5659b10354d5f5daf69c3474d476705f 04-Jul-2012 philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> fix 302709 valgrind for ARM needs extra tls support for android emulator

Allow Valgrind to run on android emulator.
+ added README.android_emulator giving some details about versions used.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12710 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
5db15403e889d4db339b342bc2a824ef0bfaa654 07-Jun-2012 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Merge in a port for mips32-linux, by Petar Jovanovic and Dejan Jevtic,
mips-valgrind@rt-rk.com, Bug 270777.

Valgrind: changes to existing files.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12616 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
ccb843b2ba2c176708bfa1764ca8e4db31722e90 26-Feb-2012 florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> Tighten up initial guest/shodow state on s390x.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12404 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
90ffbe3cc96002ab396de87fb78930f6059ece82 21-Feb-2012 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> x86: don't forget to initialise guest %es from the host %es when
constructing the initial guest register state. Fixes #291253.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12394 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
ec062e8d96a361af9905b5447027819dfbfee01a 23-Oct-2011 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Update all copyright dates, from 20xy-2010 to 20xy-2011.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12206 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
6a1ec6bdd8ac1d79e721415e7f9e6247ece2ec8e 12-Jul-2011 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Duh, do r11879 correctly (Android doesn't have an auxv entry called
AT_FPUCW.)


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11880 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
c19a5b043a10eb0477f34e66c614ca3a382edab7 12-Jul-2011 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Android doesn't have an auxv entry called AT_FPUCW.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11879 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
2a31239309f89ea2d70c1bd29d2c1a7874e14812 26-Jun-2011 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Add support for PIC executables (e.g. firefox on Ubuntu 11) by adding
the "auxv" protocol packet to gdbsrv. (Philippe Waroquiers,
philippe.waroquiers@skynet.be). Bug 214909 comment 108.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11836 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
6c55ba06bdeb9c088bf5d6dec325bb29d1dcafef 04-May-2011 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> setup_client_stack: use have_exename to consistently guard uses
of VG_(args_the_exename), thereby avoiding a potential segfault.
Spotted by IBM's BEAM checker.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11724 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
6c591e15c1d6402a2a755310f005f795b68e7e38 11-Apr-2011 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Create new module m_libcsetjmp, which wraps up uses of
__builtin_setjmp and __builtin_longjmp so that they can be selectively
replaced, on a platform by platform basis. Does not change any
functionality. Related to #259977.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11687 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
d2be8cc17fed04cbd701e9a2cc1cf365ff45cc44 28-Mar-2011 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Remove a bunch more warnings generated by gcc-4.6 about dead
assignments ("[-Wunused-but-set-variable]"), on ppc32-linux and
ppc64-linux.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11674 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
b5b87408c0c99f9f6938d8cd921e2a5f420577c4 07-Mar-2011 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Add a port to IBM z/Architecture (s390x) running Linux -- Valgrind
side components. (Florian Krohm <britzel@acm.org> and Christian
Borntraeger <borntraeger@de.ibm.com>). Fixes #243404.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11604 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
a3551be497f6c4afc5dfbbbcd7c7a955a68fb22b 09-Sep-2010 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> arm-linux: determine whether the host supports Neon by looking at our
AUXV at startup, rather than by trying to execute a Neon instruction
and seeing whether it SIGILLs. Apparently the latter is not a
reliable way to ascertain the presence of usable Neon support. Fixes
#249775.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11347 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
9dcfdffec13e259386e088f9be86ea8b8e2756c0 22-Aug-2010 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Merge from branches/THUMB: track renaming of guest_R15 to guest_R15T.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11278 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
9eecbbb9a9cbbd30b903c09a9e04d8efc20bda33 03-May-2010 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Update copyright dates to 2010.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11121 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
e9dd322e97711b2b399b0523163cf7e819425209 15-Feb-2010 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Add debug printing for the env-mashing machinery, to help investigate
#215914 ("Valgrind inserts bogus empty environment variable").



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11041 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
59570ffbe31930ab4d678754daaeec0715117a3d 01-Jan-2010 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Merge from branches/ARM, all parts of the ARM-Linux port except for
the changes to do with reading and using ELF and DWARF3 info.
This breaks all targets except amd64-linux and x86-linux.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10982 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
9bb8119b2ba66c8f93d0ba9e137332382990d6cd 07-Sep-2009 tom <tom@a5019735-40e9-0310-863c-91ae7b9d1cf9> Unmap the vdso as well as suppressing it by dropping the auxv
entry as on some systems the vdso will be at a random address
and can conflict with things like wine that need to tightly
control where things are mapped.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10886 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
20a8a6125459a919a9561f8480b38f78f7c91fe9 04-Sep-2009 tom <tom@a5019735-40e9-0310-863c-91ae7b9d1cf9> Support AT_EXECFN in the ELF auxv, filling it in with the path of
the client executable valgrind is starting.

Based on a patch from John Reiser.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10885 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
c880930fdabebbe59dd2c1f72f707cf95c796f1e 04-Sep-2009 tom <tom@a5019735-40e9-0310-863c-91ae7b9d1cf9> Add support for AT_BASE_PLATFORM in the ELF auxv.
Based on patch from John Reiser.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10884 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
8b68b64759254d514d98328c496cbd88cde4c9a5 24-Jun-2009 njn <njn@a5019735-40e9-0310-863c-91ae7b9d1cf9> This commit merges the BUILD_TWEAKS branch onto the trunk. It has the
following improvements:

- Arch/OS/platform-specific files are now included/excluded via the
preprocessor, rather than via the build system. This is more consistent
(we use the pre-processor for small arch/OS/platform-specific chunks
within files) and makes the build system much simpler, as the sources for
all programs are the same on all platforms.

- Vast amounts of cut+paste Makefile.am code has been factored out. If a
new platform is implemented, you need to add 11 extra Makefile.am lines.
Previously it was over 100 lines.

- Vex has been autotoolised. Dependency checking now works in Vex (no more
incomplete builds). Parallel builds now also work. --with-vex no longer
works; it's little use and a pain to support. VEX/Makefile is still in
the Vex repository and gets overwritten at configure-time; it should
probably be renamed Makefile-gcc to avoid possible problems, such as
accidentally committing a generated Makefile. There's a bunch of hacky
copying to deal with the fact that autotools don't handle same-named files
in different directories. Julian plans to rename the files to avoid this
problem.

- Various small Makefile.am things have been made more standard automake
style, eg. the use of pkginclude/pkglib prefixes instead of rolling our
own.

- The existing five top-level Makefile.am include files have been
consolidated into three.

- Most Makefile.am files now are structured more clearly, with comment
headers separating sections, declarations relating to the same things next
to each other, better spacing and layout, etc.

- Removed the unused exp-ptrcheck/tests/x86 directory.

- Renamed some XML files.

- Factored out some duplicated dSYM handling code.

- Split auxprogs/ into auxprogs/ and mpi/, which allowed the resulting
Makefile.am files to be much more standard.

- Cleaned up m_coredump by merging a bunch of files that had been
overzealously separated.

The net result is 630 fewer lines of Makefile.am code, or 897 if you exclude
the added Makefile.vex.am, or 997 once the hacky file copying for Vex is
removed. And the build system is much simpler.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10364 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
9c6533d2c47883f9e491a2a388c5503b3bf4c002 28-May-2009 tom <tom@a5019735-40e9-0310-863c-91ae7b9d1cf9> Add support for AT_RANDOM to keep glibc happy when it is built
to assume kernel 2.6.29 or later. Closes #194429.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10160 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
63ae69a7464f3cb383ea0b079f6ae5a8622a2c8f 19-May-2009 njn <njn@a5019735-40e9-0310-863c-91ae7b9d1cf9> Sync m_initimg with the DARWIN branch.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9935 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
cda2f0fbda4c4b2644babc830244be8aed95de1d 18-May-2009 njn <njn@a5019735-40e9-0310-863c-91ae7b9d1cf9> Merged non-Darwin-specific parts of r9397,r9423,r9490, 9461, 9462 from the
DARWIN branch. A big ugly DARWIN/trunk sync commit, mostly to do with
changing the representation of SysRes and vki_sigset_t. Functionality of
the trunk shouldn't be changed by it.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9876 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
4c245e595b9f6300d3120408ca873f7115d9cc7d 16-Mar-2009 njn <njn@a5019735-40e9-0310-863c-91ae7b9d1cf9> Fix all the non-VEX problems identified with the Clang Static Analyzer.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9416 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
9f207460d70d38c46c9e81996a3dcdf90961c6db 10-Mar-2009 njn <njn@a5019735-40e9-0310-863c-91ae7b9d1cf9> Updated copyright years.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9344 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
6bf365c2d4e55cb109d20e0a8f90dc121bdc003f 11-Feb-2009 njn <njn@a5019735-40e9-0310-863c-91ae7b9d1cf9> Changed the way files are installed. Instead of going into
$INSTALL/<platform>/<filename>, they go to $INSTALL/<filename>-<platform>.
These filenames match those built in the build tree, and so simplifies the
build system signficantly and avoids the horrible sed renamings that were
previously required. This will also help greatly with the treatment of
.dSYM debug directories in the DARWIN branch.

Files affected include:
- preload libraries such as vgpreload_core-<platform>.so and
libmpiwrap-<platform>.so
- libraries such as libcoregrind_<platform>.a
- executables such as memcheck-<platform>

I updated the manual and added a note to the NEWS file about the change,
because it will affect a small number of users.

I did my best to update the AIX launcher/initimg correctly, but it hasn't
been tested.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9135 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
91772d140e9f918c25b9b20233d3673367b799df 21-Jan-2009 njn <njn@a5019735-40e9-0310-863c-91ae7b9d1cf9> - Split up m_ume.c into m_ume/{main,elf,script}.c. This will make merging
the DARWIN branch easier later.
- Remove the disabled vgtest_ume test, it's very unlikely it'll ever work
again.
- Move VG_(find_auxv) to initimg-linux.c, the only place it's used, and make
it static.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9004 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
f093c8cdfd74111399fa3d609c2a5512c029e9db 03-Dec-2008 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Assert that the guest state size is a multiple of 16, not 8.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8804 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
9c606bd8634cd6b67bb41fa645b5c639668cfa2d 18-Sep-2008 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Merge all remaining changes from branches/PTRCHECK. These are some
relatively minor extensions to m_debuginfo, a major overhaul of
m_debuginfo/readdwarf3.c to get its space usage under control, and
changes throughout the system to enable heap-use profiling.

The majority of the merged changes were committed into
branches/PTRCHECK as the following revs: 8591 8595 8598 8599 8601 and
8161.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8621 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
a0b6b2cf9abc7b0d87be1215a245eaccc0452af9 07-Jul-2008 bart <bart@a5019735-40e9-0310-863c-91ae7b9d1cf9> Merged FORMATCHECK branch (r8368) to trunk.

git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8369 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
7cf4e6b6aed533af53339f36099ed244dc4a5b7f 01-May-2008 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Merge branches/OTRACK_BY_INSTRUMENTATION into the trunk. This adds
support to Memcheck for tracking the origin of uninitialised values,
if you use the --track-origins=yes flag.

This currently causes some Memcheck regression tests to fail, because
they now print an extra line of advisory text in their output. This
will be fixed.

The core-tool interface is slightly changed. The version number for
the interface needs to be incremented.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7982 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
4d474d086188fd1f29fa97dbd84d8ea2e589a9b8 11-Feb-2008 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Update copyright dates ("200X-2007" --> "200X-2008").


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7398 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
95d86c091a218e904e912354efa4f952a9712e82 18-Dec-2007 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Improve handling of programs which require very large main thread
stacks. Instead of hardwiring the main thread stack to a max of 16MB
and segfaulting the app beyond that point, allow the user to specify
the main stack size using the new flag --main-stacksize=<number>.

If said flag is not present, the current default, which is "MIN(16GB,
current ulimit -s value)", is used.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7302 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
d5c3f2839495d785ccf8e70c060eb2671507c192 16-Dec-2007 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Print a nice message if allocation of the stack fails, rather than just
asserting.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7301 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
5bdfbd29e26bc536c0779ec2e6b85bbb0ebd622c 15-Dec-2007 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> When allocating space for the client stack on Linux, take notice of
the --max-stackframe value. This makes it possible to run programs
with very large (primary) stack requirements simply by specifying
--max-stackframe.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7300 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
14c7cc5a5fbe9526329f058116f921988efe679e 25-Feb-2007 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Get rid of the type XArrayStrings in m_clientstate and use new generic
equivalents in module m_xarray instead. A suprisingly pervasive
change.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6616 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
9ebd6e0c607fa30301b1325874eb8de871c21cc5 08-Jan-2007 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Update copyright dates.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6488 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
f9d2f9b5ec3b8febc8465c05e90c8a5f6de3d6a4 17-Nov-2006 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Redo the interface to m_initimg (module for setting up the initial
client image) so it's less of an incomprehensible mess. Basically the
idea is to have two standard functions, VG_(ii_create_image) and
VG_(ii_finalise_image), which communicate using the structure types
IICreateImageInfo and IIFinaliseImageInfo. The types hold various
OS-specific bits of info. A nice side effect is that m_main is tidied
up somewhat.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6357 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
2da47846e4b5b258fbe09053c4daf9f4f5773109 17-Oct-2006 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Merge r6102/6103:

A new module ("Initial Image"), whose purpose is to set up the
client's initial memory and register state before running it. On
Linux this does all the stack/auxv/envp stuff which was previously
done in m_main. On AIX5 the kernel prepares the process' initial
image, so there's nothing to be done there. But LD_PRELOAD doesn't
work on AIX5, so m_initimg sets up the client so as to start by
running a short bit of code which gets the kernel to load in the core
and tool preloads and then start the client.

As a result of this, m_main gets a lot shorter and cleaner.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6251 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c
17c110443e39c0c63bb298689cad31e0b4671dfe 15-Oct-2006 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Move code that creates the initial Linux memory image (stack, env,
etc) from m_main into m_initimg.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6234 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_initimg/initimg-linux.c