valgrind.h. Although these requests are not implemented by the core, they can
be implemented by skins that track heap blocks, eg. Memcheck, Annelid, Massif.
This is in preparation for committing Massif to the repository.
I think I managed to make the change in a binary-compatible way. The only
inconvenience for users is that if they have a client program compiled with the
old requests in, Valgrind will abort with an explanatory message that tells
them to recompile. Once they've done that (no changes to their program are
required), it works again.
I even updated the docs.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1881
requests from the Memcheck requests and putting the descriptions in the
appropriate parts of the docs.
Removed the __VALGRIND_SOME_SKIN_H test -- it was designed to prevent people
#including valgrind.h when they probably want memcheck.h, but it's actually a
reasonable thing to do to #include valgrind.h alone, because there are some
requests in valgrind.h.
Removed references to VALGRIND_MAKE_NOACCESS_STACK from the docs, as it doesn't
exist in the implementation.
Fixed a few other minor things.
MERGE TO STABLE
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1880
fragile, and it was lucky that it worked at all. Replaced it with a much more
robust method. Thanks to Dirk Mueller for pointing it out.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1879
is PUTed into %ESP, we do *know* that this tempreg points to %ESP afterwards,
so track it.
reduces the amount of expensive "DO_GENERIC" calls by 75% in Khtml. I've
not observed a problem with it, but consider it experimental.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1878
don't just call the unmangled versions, but do the appropriate stuff
themselves directly (this was necessary for Massif). This means that stack
traces for them have one fewer function. And I was able to gather up several
very similar functions into a macro, reducing the amount of code, which was
nice. Had to update one regtest's expected output accordingly.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1875
number, will print it with commas delimiting it. Very useful when printing
large numbers.
Using it, was able to remove the wretched commify() function from Cachegrind.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1869
with being called from SK_(pre_clo_init)(), before its startup code has been
run (just returns 0).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1868
rather than "make clean", which is the behaviour recommended by the automake
docs for files built at configure-time.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1859
them in a shared place. (They used to be different, when Addrcheck didn't
distinguish between reads and writes, but now they're the same.)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1837
and Nick but got no reply. I guess they're okay with it. I tested them
quite a lot so it should be fine.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1834
message if so. If anyone thinks this will break anything, please yell.
Updated FAQ #5 correspondingly, added info on how to combine static and dynamic
libraries.
MERGE TO STABLE(?)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1831
Renamed:
VG_(read_procselfmaps_contents)() --> VG_(read_procselfmaps)()
VG_(read_procselfmaps)() --> VG_(parse_procselfmaps)()
VG_(read_symbols)() --> VG_(read_all_symbols)()
VG_(read_symtab_callback)() --> VG_(read_seg_symbols)()
Removed the Bool 'read_from_file' arg from (what is now)
VG_(parse_procselfmaps)(). If /proc/self/maps needs to be read beforehand, the
code calls (what is now) VG_(read_procselfmaps)() before. Still using the
static buffer which is not nice but good enough.
More importantly, I split up VG_(new_exe_segment)() into
VG_(new_exeseg_startup)() and VG_(new_exeseg_mmap)(). This is because at
startup, we were stupidly calling VG_(read_symbols)() for every exe seg, which
parses /proc/self/maps completely in order to load the debug info/symbols for
the exe seg (and any others we haven't already got the symbols for). Despite
the fact that the startup code reads /proc/self/maps to know which segments are
there at startup. In other words, we were reading /proc/self/maps several
times more often than necessary, and there were nested reads, which Stephan
Kulow's recent depth patch fixed (but in a pretty hacky way; this commit fixes
it properly). So VG_(new_exeseg_startup)() now doesn't cause /proc/self/maps
to be re-read. Unfortunately we do have to re-read /proc/self/maps for mmap(),
because we don't know the filename from the mmap() call (only the file
descriptor, which isn't enough).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1830
Fixed now.
MERGE TO STABLE (assuming that Addrcheck does overlap checking in STABLE, which
I think it does)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1828
scream if you don't like this.. Personally I've never seen a valid
warning and all of them were spurious.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1826
read_procselfmaps calls *record_mapping which
is startup_segment_callback for init_memory. But this
again calls through read_symbols read_procselfmaps
again with read_from_file == True. But this overwrites
the internal buffer and causes parsing errors.
(What makes the error a bit funny is that valgrind
wouldn't have catched that error afaik :)
Anyway: our solution is to forbid read_from_file from
with callbacks
MERGE TO STABLE
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1820
how stack snapshots are taken and printed; they can be used in preference
to VG_(get_ExeContext)() and VG_(pp_ExeContext)(). These are used by
Massif, my heap profiling skin.
Changed --num-callers to allow a backtrace size of 1.
Added code so that when Valgrind fails to disassemble an instruction, the
instructions line/file and address are printed out, which makes it easier to
work out where and what it is. Required the stack snapshot changes above.
MERGE TO STABLE?
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1819
