(no functional changes, except that these values will be visible
in the dwarf trace, instead of DW_AT_???)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14611
The fix committed in revision 14603 is properly fixing the bug 339721.
However, when enabling the dwarf tracing, the DW_FORM_ref_sig8 causes
a segmentation violation, as the tracing code is shared with the
reading code. But the DW_FORM_ref_sig8 reading code is dereferencing
some data structure that is only initialised when --read-var-info=yes.
So, in case DW_FORM_ref_sig8 form reading is done and --read-var-info=no,
then check that we are tracing, and avoid dereferencing the (not initialised)
signature hash table.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14610
This change makes VG_(clo_suppressions), VG_(clo_fullpath_after),
and VG_(clo_req_tsyms) XArrays. They used to be arrays of fixed size.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14609
The change eliminates the fixed size buffers in gen_suppression and
show_used_suppressions. This is achieved by changing the return type from
VG_TDICT_CALL(tool_get_extra_suppression_info and
VG_TDICT_CALL(tool_print_extra_suppression_use from Bool to SizeT.
A return value of 0 indicates that nothing (except the terminating '\0'
which is always inserted) was written to the buffer. This corresponds to the
previous False return value. A return value which is equal to the buffer
size (that was passed in as function argument) indicates that the buffer was
not large enough. The caller then resizes the buffer and retries.
Otherwise, the buffer was large enough.
Regtested with a resize value of 1.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14606
The skip code was wrongly skipping 16 bytes, while only 8 are read
for a DW_FORM_ref_sig8.
Note that the problem is made visible by an assert when using
--trace-symtab=yes but in fact this is a real bug in the dwarf reader,
that was introduced in one of the optimisations done for the inline info.
It can manifest itself with other symptoms:
One of the 2 following assertions can fail:
vg_assert (check_sibling == sibling);
vg_assert (get_position_of_Cursor (&check_skip)
== get_position_of_Cursor (&c));
Or the following error can be given:
--29973-- WARNING: Serious error when reading debug info
--29973-- When reading debug info from /home/philippe/valgrind/trunk_untouched/memcheck/tests/dw4:
--29973-- Overrun whilst reading .debug_info section
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14603
to make it available to tools. This allows to remove quite a bit of
ifdeffery from memcheck's mc_machine.c
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14601
includes libvex.h. It isn't needed to successfully compile pub_core_basics.h
standalone and the declarations libvex.h provides aren't used as broadly as
the comment in the code implied.
Move the guest-specific includes and some ifdeffery to the new file
pub_core_guest.h
For the curious reader: The change above avoids a problem when linking the
linux-launcher which previously included libvex.h indirectly. libvex.h also
defines the inline function LibVEX_Alloc which, when emitted, causes the
link step to fail due to unresoled references (as the launcher does not link
against libvex.a). See also BZ #339542.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14600
Change callgrind's init_cmdbuf function to allocate a large enough
buffer for the command line.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14597
r14271 Audit a few buffer sizes, increase one.
r14280 Audit buffer size.
r14296 Remove a few unneeded header files.
r14310 Replace fixed size buffers with a large enough buffers.
r14338 Remove a dead assignment in print_bbcs and make global variable
print_fd a local variable.
r14359 Remove a benign macro redefinition in cachegrind.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14595
Chang the semantics of VG_(getgroups) to support querying the number
of supplementary group IDs which simplifies obtaining them and gets
rid of fixed size buffers.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14594
The change eliminates the use of fixed size buffers for path names.
There was a comment in the code that dynamic memory allocation could
not be used. But that is no longer true.
Clean up #includes.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14587
Function MC_(snprintf_delta) requires a buffer of size 31 or larger to
avoid overflow.Add an assert, change and document the buffer size and
fix all call sites. Remove magic constants along the way.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14583
In function read_dot_valgrindrc use a large enough buffer
allocated on the stack.
Also assert that the passed in directory is not NULL. This is
true at all call sites. The old code would have attempted to read
/.valgrindrc for dir == NULL and I don't think we want that.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14580
This changes VG_(record_startup_wd) to dynamically allocate a large
enough buffer for the directory name. As the dynamic memory manager has
started up a while ago, this is quite safe. Also rewrite VG_(get_startup_wd)
to simply return the directory name. No more messing with copying it
around. Adapt call sites.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14579
branch to trunk.
This change eliminates the fixed size buffers in VG_(basename)
and VG_(dirname).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14576
Disable test for darwin as pthread_setname_np is not implemented.
But setting and observing the threadname is what this test is all about.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14573
Cavium toolchain defaults to soft-float, so it is important to enable full
build of the test suite to work in that case as well.
This boils down to protecting FPU-specific code segments with
#if defined(__mips_hard_float)
#endif
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14572
Check whether the target platform is meant to have an FPU before executing
tests that make use of a floating-point unit.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14571
Extend mips_features with "hard-float" query to which mips_features will
respond whether or not the platform is meant to have a floating point unit.
The query is not a runtime check, but a built-time check.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14570
the parameter. QEMU does pass 0 nevertheless as parameter.
bugzilla: [Bug 339424] Full support of KVM ioctl
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14569
the man page to contain:
></programlisting>
<para>And here are the same errors with
<option>--read-var-info=yes</option>:</para>
<programlisting><
