simply treating R and X as equivalent but the real problem is that
mappings can appear to have X permission entirely indepenent of anything
else with recent x86 kernels.
If a mapping is inside the (deliberately constrained) code segment then
it will appear to have X permission regardless of whether R or X was asked
for when it was mapped, so what we really need to do is allow the kernel
to add X to any mapping but not to take it away if we were expecting it.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4985
normally give execute permission to memory allocated from the heap
with sbrk.
This also required fixing the smc1 test for amd64 to use mmap to
allocate memory so that it can have execute permission.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4983
was in the sigframe module has been moved into the coredump module
where it belongs and things fixed up to compiler again.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4970
it can't even read the length of the block - just report an error as we
do if there isn't enough data for the rest of the block. Fix bug #114757.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4960
unique / 30000 total to 1000 unique / 100000 total. Programs are
generally bigger now than 3 years ago.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4957
go, but realistically we can't implement it portably, at least without
considerable performance overhead and some additional complexity.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4956
performance quite a bit, since the cache is emptied quite often on
ppc32, and a smaller cache is less intrusive in the real machine's L2
cache. On x86 the change doesn't seem to have much effect.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4947
the guest extents for the presented translation and also its original
un-redirected guest address. These changes are needed in particular
to make cachegrind's code cache management work properly.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4943
find and delete all translations intersecting with small address
ranges (8 k or less, currently). This makes it possible to simulate
ppc32 icbi instructions in reasonable time, and finally makes the
ppc32 port run at a usable speed.
The scheme is based around partitioning translations into equivalence
classes based on address ranges. For deletions whose range falls
within a single class, all translations intersecting it can be found
by inspecting just that class and one other. Given that there are 256
classes, this cuts the cost, relative to scanning the entire TC, by
approximately half that factor (viz, 128), assuming the translations
are distributed evenly over the classes.
The whole business is more complex and difficult than I would like.
A detailed comment will later be added.
Very thorough sanity checking has been added
(sanity_check_eclasses_in_sector). This is engaged at
--sanity-level=4 and above.
The TT hash function (HASH_TT) has been improved to reduce its
tendency to cluster TT entries in some circumstances. This has
allowed the TT maximum loading factor to be increased from 66% to 80%
and so the absolute size of the TC (in each sector) to be less than
2^16 entries. The latter change is important for the fast-deletion
changes.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4942
checking of programs done in these two places are combined, which avoids
duplicate code and greatly reduces the number of cases in which exec()
fails causing Valgrind to bomb out.
Also, we can now load some programs we could not previously, such as scripts
lacking a "#!" line at the start. Also, the startup failure messages for
bad programs match the shell's messages very closely.
And I added a whole bunch of regtests to test all this.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4918
deal with any IR that happens to show up. This makes it work on ppc32
and should fix occasionally-reported bugs on x86/amd64 where it bombs
due to having to deal with multiple date references in a single
instruction.
The new scheme is based around the idea of a queue of memory events
which are outstanding, in the sense that no IR has yet been generated
to do the relevant helper calls. The presence of the queue --
currently 16 entries deep -- gives cachegrind more scope for combining
multiple memory references into a single helper function call. As a
result it runs 3%-5% faster than the previous version, on x86.
This commit also changes the type of the tool interface function
'tool_discard_basic_block_info' and clarifies its meaning. See
comments in include/pub_tool_tooliface.h.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4903
many 'r' sections also as 'x' because x86 can't really distinguish
them. The change just regards 'x' and 'r' as equivalent on x86.
Checking on ppc32/amd64 is unchanged.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4901
