Julian Seward [Sat, 12 Oct 2002 18:32:06 +0000 (18:32 +0000)]
merge rev 1.24:
From "Francis Lebourse" <flebourse@jetmultimedia.fr>:
[re the ELF symbol reader]
This patch tries to exploit the dynamic symbols of a library if the
standard and debug symbols are missing.
This way, I avoid the "object doesn't have a symbol table message"
message and valgrind is able to print meaningful backtraces (else you
have only "in libsomelib.so"), even in the case of stripped libs.
Since the check of the .dynsym/.dynstr sections is done before the
.symtab/.strtab sections, the previous behavior is preseved for
unstripped libraries.
Julian Seward [Sat, 12 Oct 2002 18:25:42 +0000 (18:25 +0000)]
merge rev 1.28:
Fixes for the DWARF2 reader, from Josef Weidendorfer:
Attached patch is for the Dwarf2 source line info reader;
For reading, a state machine is used reconstructing source line
info while running and reading (see DWARF2 specification, ch. 6.2).
The state machine was correct, but the calls to addLineInfo()
were wrong: It reported most of the times too small ranges
for source code statements, because it used only the diff of the last
state machine command instead of the diff to the last statement
boundary. Effect: Around 1/3 of all addresses with source line info got
unknown location.
The patch adds a "last_address" to the state machine to remember the last
statement boundary. On reset, it#s initialised to the "invalid" address 0. I
hope this is OK (or should we use "(Addr)-1" instead?).
The patch now uses the "is_stmt" boolean correctly to only call addLineInfo()
if there's a statement boundary (on x86, is_stmt most probably is
always true...).
Add as many suppressions as I reasonably can for SuSE 8.1. There's
still a lot of junk, but that can only be fixed by a more direct
tackling of gcc-3.2's bad habits.
Fix stupid bug in which vg_push_signal_frame/vg_pop_signal_frame assumed
that the handler wouldn't change the signal-number parameter it was passed.
Fixes this:
vg_signals.c:1065 (vgPlain_signal_returns):
Assertion `sigNo >= 1 && sigNo <= 64' failed.
and possibly arbitrary other mutancy in the signal handling too.
pthread_kill would incorrectly deliver a signal to a thread even if
the thread currently had the signal blocked. Fixed. It _may_ also
fix some assertion failures in scheduler_sanity() in vg_scheduler.c.
Kludge to work around the problem thatthe /usr/include/sys/user.h on
R H 6.2 doesn't define struct user_fpxregs_struct (problem appeared
with Jason Molenda's ptrace patch).
Reduce polling delays in poll(), select(), pause() and in the scheduler
idle loop. This reduces some strange non-CPU-bound delays under certain
circumstances.
When the client tries to __NR_close() our logfile, claim the close
succeeded, which is a lie since we just ignore it -- otherwise the
log disappears at that point.
Fixed two CPUID auto-cache detection problems reported by Guillaume Laurent:
- Some Intel cases were missing, giving spurious warnings such as:
--18114-- warning: Unknown Intel cache config value (0x50), ignoring
- The 0x40 case was wrong... its meaning depends on whether you have a P6
core ("no L2 cache present") or a P4 core ("no L3 cache present").
Damn wretched Intel CPUID format.
I was unwittingly assuming P6 cores which meant that P4 cores reporting
no L3 got this bogus warning:
--18114-- warning: L2 cache not installed, ignore L2 results.
So I now don't do anything for that case, and detect a missing L2 cache
by checking if its set by any of the other entries.
Turns out neither was affecting the results, but better to get rid of them
anyway.
Guillaume tested the changes for me so hopefully they work.
Include %defattr(-,root,root) in valgrind.spec.in so that the
ownership of the files is correct even if a non-root user builds the
RPM package. (Matthias Andree <matthias.andree@stud.uni-dortmund.de>)
valgrind's strcmp() implementation (to clients) treats char as signed
whereas the libc implementation it replaces treats char as unsigned.
Fix! God knows how anything much ever worked before now.
In order to handle FPU instructions with data size of 28 and 108 bytes,
implemented a hack: such instructions have their data_size reduced to 16
bytes for cache simulation purposes, to avoid assertion failures coming from
transfers that involve more than two cache lines. Should occur rarely in
practice.
Fixed a big problem with Cachegrind. I was assuming that any instruction that
both read and wrote memory must be doing it to the same address, and was thus
modifying it (eg. 'incl'). But some instructions can read and write different
addresses (eg. pushl %eax, (%ebx)).
Also, it wasn't handling 'rep'-prefixed instructions correctly. The way they
were instrumented meant that an I-cache access was simulated for every
repetition they do, which is most probably not accurate; only one I-cache
access should be simulated.
Fixed both of these. Some largeish changes required, unfortunately:
- Added 'iddCC' type, the cost-centre for instructions that read and write
different addresses. Correspondingly added READ_WRITE_CC as a CC_type.
- Have to do more correspondingly more complicated things to detect what
CC_type an x86 instruction is.
- To handle 'rep' prefixes, now do the I-cache access for such instructions
before the JIFZ UInstr, so only 1 I-cache access is simulated. D-cache
accesses are still done in the same place, so they occur once per
repetition.
- Changed the cache simulation log functions; gone from two to five, we now
have:
This means fewer spill slots (only 2, I think) have the compact call form,
which is unfortunate. Although it's not a problem in the ERASER branch in
which the helpers aren't hard-wired the way they are in this branch.
Problem was that when an exe segment was unloaded, cachesim_notify_munmap() was
being called after symbols were unloaded. But it needs the symbols to do the
lookup required to remove the BBCCs. It was only working some of the time
for exe segments that didn't have any symbols(!)
Fix: now invalidate translations first, unload symbols second. This required
adding VG_(is_munmap_exe)() to determine if an unloaded segment is executable.
Julian Seward [Sun, 25 Aug 2002 20:07:16 +0000 (20:07 +0000)]
1. The license is actually in the file COPYING, not LICENSE as all
the sources claim. Automake seems to have some hard-wired notion
that the license file must be called COPYING, so we have to
rename in all the source files :-(
2. Change the license for valgrind.h ONLY to a BSD-style license
so people can include it in their code. The entire rest of
the system remains under the GPL.
Julian Seward [Tue, 20 Aug 2002 18:18:54 +0000 (18:18 +0000)]
Merge rev 1.16.4.8 from ERASER into VALGRIND_1_0_BRANCH:
Added Cyrille Chepelov's patch for identifying cache params of Duron stepping
A0 which has a bug that causes CPUID to misreport L2 cache size. Untested, I
can only assume it works as I don't have such a machine to try with.
Julian Seward [Tue, 6 Aug 2002 09:06:18 +0000 (09:06 +0000)]
Merge rev 1.91:
Simulate resolver-specific state as per the real libpthread.so, wherein
the root thread (tid 1) always uses _res as exported from libc.so as its
state. This fixes the name lookup problems in KAtlantik.
Only run __libc_freeres() when valgrinding. It may do invalid free()s
which cause the low-level memory manager to crash. When valgrinding
that's all protected, but not when cachegrinding etc.
projects / thirdparty / valgrind.git / log
