the dirname_available parameter. It's redundant. The value
of the returned directory name can be tested instead.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14814
Left justification of strings in myvprintf_str was mixed up.
Now fixed and %s formats changed accordingly.
In function myvprintf_int64: the local buffer was not large
enough to hold ULONG_MAX in binary notation. Numbers were
truncated at 39 digits.
Testcases added.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14808
Use proper initialisation functions for the type and variable parser.
Add functions to release the dynamically allocated functions.
No longer maintain content of popped-off stack entries as that is
essentially freed memory and complicates matters unnecessarily.
Part of fixing BZ #337869.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14801
Two things:
- remove the buffer argument from VG_(DebugInfo_sect_kind)
- allocate AddrInfo::SectKind::objname dynamically
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14719
In the non-XML part buf_dirname was read without observing the
know_dirinfo guard. Now fixed. Initialise buf_dirname nevertheless.
Also remove a dead assignment.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14707
(a) the 2nd argument must not be NULL
This was true anyhow and requiring it allows us to simplify the function
by eliminating the local buffer.
(b) the memory pointed to by the 2nd argument is always initialised
In the past the output file name was not initialised in case VG_(open)
failed 10 times in a row. The call sites in m_main.c and m_gdbserver/target.c
were reading the uninitialised filename unconditionally. This was spotted
by IBM's BEAM checker.
Fix call sites, eliminate some magic constants along the way.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14706
(/system/bin/ls, /system/bin/date) run. Still to do:
* enable more malloc/free intercepts
* enable wrappers for ashmem and binder syscalls
* check to see if any special ioctl support is required for ARM Mali GPUs
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14690
Changes VG_(describe_IP) to return the untruncated result in a statically
allocated local buffer. Fix call sites and update two .exp files who had
truncated names.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14685
The functions VG_(get_filename) and VG_(get_filename_lineno) now return
a pointer to filename and directory name instead of copying them into
buffers passed in from the caller.
The returned strings are persistent as long as the DebugInfo to which
they belong is not discarded. The caller therefore needs to stash them
away as needed.
Function VG_(strncpy_safely) has been removed as it is no longer needed.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14668
This patch changes the interface and behaviour of VG_(demangle) and
VG_(maybe_Z_demangle). Instead of copying the demangled name into a
fixed sized buffer that is passed in from the caller (HChar *buf, Int n_buf),
the demangling functions will now return a pointer to the full-length
demangled name (HChar **result). It is the caller's responsiblilty to
make a copy if needed.
This change in function parameters ripples upward
- first: to get_sym_name
- then to the convenience wrappers
- VG_(get_fnname)
- VG_(get_fnname_w_offset)
- VG_(get_fnname_if_entry)
- VG_(get_fnname_raw)
- VG_(get_fnname_no_cxx_demangle)
- VG_(get_datasym_and_offset)
The changes in foComplete then forces the arguments of
- VG_(get_objname) to be changed as well
There are some issues regarding the ownership and persistence of
character strings to consider.
In general, the returned character string is owned by "somebody else"
which means the caller must not free it. Also, the caller must not
modify the returned string as it possibly points to read only memory.
Additionally, the returned string is not necessarily persistent. Here are
the scenarios:
- the returned string is a demangled function name in which case the
memory holding the string will be freed when the demangler is called again.
- the returned string hangs off of a DebugInfo structure in which case
it will be freed when the DebugInfo is discarded
- the returned string hangs off of a segment in the address space manager
in which case it may be overwritten when the segment is merged with
another segment
So the rule of thunb here is: if in doubt strdup the string.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14664
that once an element has been allocated and added to the pool it must
not be modified afterwards. See the documentation in pub_tool_deduppoolalloc.h
The rest of the patch is ripple.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14654
This is (a) consistent with how the other containers are defined
and, more importantly, (b) allows the constification of the hash table API.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14639
truncate overlaps in the DebugInfoMappings that have been collected by
the DebugInfo's FSM. Not doing so can confuse ML_(read_elf_debug_info)'s
computation of bias values. Observed to be a problem when reading EDIDX
sections for objects mangled by Mike Hommey's elfhack program.
See http://bugzilla.mozilla.org/show_bug.cgi?id=788974
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14632
Change VG_(resolve_filename) to not truncate the result which is returned
in a static buffer now. Fix callsites.
Simplify VG_(di_notify_pdb_debuginfo) to use VG_(resolve_filename).
Fix VG_(readlink) prototype.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14628
(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 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
Since valgrind 3.9.0 the STABS support was already disabled completely.
But the code was still there being compiled and we were still searching
for stabs sections in binaries. Completely remove all sources, tests and
references. Add a note to coregrind/m_debuginfo/README.txt to mention
the old code can be found in the subversion repository.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14550
Tool files shall use tl_assert not vg_assert.
Fix code accordingly.
Adapted check_headers_and_includes to make sure the code
stays clean in that respect.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14542
- Document that the allocation function must ot return NULL.
- As a conequence of the previous requirement the various Create and AllocNode
functions cannot return NULL. Remove pointless asserts at call sites.
- Remove documentation of undefined function CreateWithCmp.
- Names of library functions (such as 'free') are reserved as a are names
beginning with underscores. Don't use those.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14531
readstabs.c tries to include a.out.h to get the stabs symbol list entry
definition. STABS isn't specifically tied to the a.out format though.
The symbol entry structure just happens to be defined in the a.out.h
header. The header isn't really standard though. It might be provided
by glibc or the kernel in different locations. And not all arches support
the a.out format so the header might not even exist. Just define the
needed nlist struct entry directly in readstabs.c for VGO_linux. All
arches in glibc and the kernel use the same one anyway.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14484
This patch avoids dereferencing absori that are in other CUs than
the CU currently being read.
This avoids dwarf reading errors when reading inlined information.
The bypass results in inlined function being reported as
UnknownInlinedFun rather than the real correct function name.
--read-var-info=yes is still broken for unknown reasons
(probably type reading is doing some other cross-CU references ?).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14476
Revision r14464 made it so that debug alt files could be found by their
build-id or their (relative) file path. Debug alt files are matched using
the given build-id, but by crc. Calculating the full CRC is costly, but
currently still needed to avoid misidentifying the main file as debug
file. Slightly more efficient would be to use fstat to check we aren't
actually opening the main file under any other name (but that only works
for local DiImages). Or we could check that the file being opened actually
has at least one .debug* section. But this change was the minimal patch
to make things work as before.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14474
readdwarf3 would only look for alt dwz files using the build-id.
But alt files can be installed relative to the debug (or main) file.
Fix find_debug_file to allow searching of relative files even if
we don't want an ET_REL (rel_ok) file, and pass the build-id to
open_debug_file so it can be checked. Add the debug file path to
_DebugInfoFSM and set it in find_debug_file once opened. Pass the
dbgname or filename as relative file to resolve an altfile in
read_elf_debug_info when we ahava an debugaltlink_escn.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14464
which, despite the name, is a pointer to an unsigned long.
So we should be passing arguments of matching type.
Spotted by the Coverity checker.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14431
(used for ppc64 platforms) #ifdef-ed and accessed by macros
that becomes NOP on non ppc64 platforms.
This decreases the debuginfo memory by about 2.5 Mb on a big 32 bit application.
Note : doing that, some questions were encountered in the way
tocptr and local_ep have (or do not have) to be copied/maintained
in storage.c canonicaliseSymtab
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14273
