Julian Seward [Mon, 5 May 2003 22:26:52 +0000 (22:26 +0000)]
Merge rev 1.41:
Merge patch from JosefW:
Hi,
recently I found that there is sometimes cost attributed to some
strange lines (with cachegrind/calltree) with GCC 3.x (using the
DWARF2 debug info format).
I had time to look at this. There is a bug in the DWARF2 debug line
info loader when instructions following each other have source lines
far from each other (e.g. with inlined functions).
Julian Seward [Mon, 5 May 2003 00:09:41 +0000 (00:09 +0000)]
Merge rev 1.16:
Couple of minor fixes:
- don't keel over if run on an empty file
- abort if the "summary:" line is missing; previously it gave a warning
and tried to keep going but then other things broke.
Julian Seward [Mon, 5 May 2003 00:05:15 +0000 (00:05 +0000)]
Merge rev 1.89:
Don't call VG_(mash_LD_PRELOAD_and_LD_LIBRARY_PATH) if all we're doing
is exiting normally. There's no point, and it causes breakage when
programs which write their environment variables, finish normally.
Fix threading problems on glibc-2.3.2 or later. Note this is *not*
NPTL support.
The behaviour of weak vs strong symbols seems to have changed in
glibc-2.3.2. This caused problems in coregrind/vg_intercept.c,
wherein strong symbols in vg_libpthread.c were intended to
override weak symbols in vg_intercept.c, in order to give alternative
thread-safe implementations of some functions, poll(), select(), etc.
The change involves moving the nonblocking implementations of poll, etc
into vg_intercept.c, renaming them to (eg) VGR_(poll), and routing
all calls to poll to VGR_(poll) [dually for other such fns]. This
means even single-threaded programs now use these functions, but
that doesn't strike me as harmful.
Record the correct address of the initial thread's stack, as determined
by the initial scan of /proc/self/maps, so that we correctly identify
addresses in it. This fix is thanks to Dirk Mueller.
Unchain translations when doing VALGRIND_DISCARD_TRANSLATIONS. Otherwise
the tt/tc are left in an inconsistent state afterwards. (Adam Gundy
<arg@cyberscience.com>)
A minimal set of changes to make it work on Red Hat 9, at least in the
interim. All hats off to Graydon Hoare for this, plus to whoever
devised the LD_ASSUME_KERNEL trapdoor.
This does not provide NPTL support. Instead it turns out we can ask
for the old LinuxThreads interface to be used (wonderful!)
Other than that we have to deal with kernels with SYSINFO pages at the
top of memory. No big deal, apparently.
--------------
Add and use a configure test to determine if this is an NPTL based
system. Hopefully this will allow it to build out of the box and
(sort-of) work on RH9.
Julian Seward [Sat, 15 Mar 2003 18:39:57 +0000 (18:39 +0000)]
Merge rev 1.8:
vg_profile.c, which is #included by skins that want to profile, was using some
core only functions (vg_assert and VG_(core_panic)), which screwed things up.
Replaced them with the skin versions. I don't know how this ever worked.
Added a stderr filter for new_override, that removes the exact numbers for
malloc, because different glibc versions seem to allocate different amounts of
memory.
Julian Seward [Tue, 25 Feb 2003 23:49:46 +0000 (23:49 +0000)]
Make CXXFLAGS be the same as AM_CXXFLAGS, so the correct options are
used to build the regression tests. I don't know if this is really
the correct way to fix this problem. I don't understand why
AM_CXXFLAGS aren't used by default for C++, seeing as how AM_CFLAGS
evidently are used for C sources.
Julian Seward [Mon, 24 Feb 2003 21:55:34 +0000 (21:55 +0000)]
o I fixed a small bug: the code in coregrind/vg_syscalls.c seems
to assume that all sockaddrs are non-NULL and non-zero in
length. This isn't always true, and when I ran a program that
used a NULL sockaddr through Valgrind it segfaulted. I believe
that the change that I made fixes this bug in general, but I
might be overlooking something.
Fixed demangler bug -- it was relying on glibc for some functions. This
triggered an incredibly obscure bug in my experimental skin -- memcpy() was
called within the demangler at (about?) the same time as the dynamic linker was
fiddling with the memcpy() entry, which caused one word of memory (probably
some counter in the dynamic linker) to be incremented, which my skin didn't
like.
So I removed all (AFAICT) of the demangler's dependencies on glibc. This
required adding macros for memset, memcpy, strlen, strcmp..., to replace them
with their VG_(...) version. The only #includes now are to .h files that are
part of Valgrind.
Also required #defining "size_t" as "Int".
Also required adding VG_(memcmp)() to vg_mylibc.c.
Also removed the "-1 == EOF" part of the compile-time test in safe-ctype.h
that checks the character set is ASCII. This was to remove the dependency
on stdio.h. Slightly dodgy, but should be ok I think/hope.
Julian Seward [Sun, 23 Feb 2003 03:54:59 +0000 (03:54 +0000)]
Initial rough hack to spot the stack segment at startup by looking
for a rwx mapping which contains the startup %esp.
Might be better to look for just rw-. Stack might not be executable
if there's a noexec patch, and x86-64 actually enforces the x bit
distinctly from r.
Julian Seward [Sun, 23 Feb 2003 03:00:29 +0000 (03:00 +0000)]
Apply the following:
The veneers for msgrcv in vg_intercept.c and vg_libpthread.c are not
returning the number of bytes read correctly - they always return zero
for any non-error case, which causes programs using msgrcv to behave
somewhat non-optimally when running under valgrind ;-)
Attached is a patch against 1.9.3 which fixes this.
Julian Seward [Sun, 23 Feb 2003 01:25:51 +0000 (01:25 +0000)]
Initial rough hack to spot the stack segment at startup by looking
for a rwx mapping which contains the startup %esp. This should be
more robust than the previous mechanism, which checked a small number
of known places and gave up if none matched. This change is motivated
by Gentoo Linux's high security mode, in which the stack location is
chosen randomly for each new process.
Thanks to Catherine Allen for helping out on this.
Fixed a minor bug -- the condition for determining whether
VG_(handle_esp_assignment)() was needed by a skin (and thus whether to register
it in the baseBlock) was different to that used when determining whether to
call it in code generation... so it could be (attempted to be) called having
not been registered.
Fixed this by consistifying the conditions, using a function
VG_(need_to_handle_esp_assignment)() that is used in both places. The bug
hadn't been found previously because no existing skin exercised the mismatched
conditions in conflicting ways.
Also took VG_(track).post_mem_write out of consideration because it's no longer
important (due to a change in how stack switching is detected).
----
Improved the error message for when a helper can't be found in the baseBlock --
now looks up the debug info to tell you the name of the not-found function.
----
Increased the number of noncompact helpers allowed from 8 to 24
----
Removed a magic number that was hardcoded all over the place, introducing
VG_MAX_REGS_USED for the size of the arrays needed by VG_(get_reg_usage)()
Made VGOFF_(helper_idiv_64_32) and all the similar helper offsets visible to
skins, so they can determine which helper is being called for CALLM
instructions.
Made the setting of VG_(details).avg_translation_sizeB optional, defaulting to
100 bytes (added VG_DEFAULT_TRANS_SIZEB). Took the now-unnecessary settings
out of Nulgrind and CoreCheck. Also made .avg_translation_sizeB a UInt (from
an Int), to avoid possibility of negatives.
Added some functions for skins to access shadow registers:
VG_(get_shadow_archreg), VG_(set_shadow_archreg), VG_(shadow_archreg_address).
Curiously, the only way skins could previously access them was with
VG_(shadow_reg_offset), which wasn't very flexible.
Renamed VG_(nameCondcode)() as VG_(name_UCondcode)() to make it consistent
with similar functions, and made it visible to skins (useful).
Also bumped up the skin interface minor version number due to this change; this
bumping will cover any other binary-compatible changes between now and the next
release (after 1.9.3).
Made more informative the error message that is shown when liveness problems
occur... this is helpful when writing skins, because it's easy for problems
with SK_(instrument)() to screw it up.
- When recording errors, VG_(dup_extra_and_update)() previously was only
called if the 'extra' field was non-NULL. Now it's always called.
This is for two reasons:
a. The 'extra' field could be holding a non-pointer value that just
happens to be 0
b. The skin might want to update the error, even if it doesn't use
the 'extra' field.
A pretty minor change that shouldn't upset anybody.
- Made the ExeContext 'where' field of an error visible to skins, by
adding VG_(get_error_where)(). This can be useful, eg. for comparing
errors for equality.
projects / thirdparty / valgrind.git / log
