|
From: <sv...@va...> - 2006-10-17 01:36:41
|
Author: sewardj
Date: 2006-10-17 02:36:37 +0100 (Tue, 17 Oct 2006)
New Revision: 6265
Log:
Merge r6128:
Interface changes for m_debuginfo:
- new fn VG_(di_aix5_notify_segchange) to notify XCOFF loads/unloads
- new fn VG_(lookup_symbol_SLOW) for looking up the address of a fn
given its name and soname
Modified:
trunk/coregrind/pub_core_debuginfo.h
trunk/include/pub_tool_debuginfo.h
Modified: trunk/coregrind/pub_core_debuginfo.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/pub_core_debuginfo.h 2006-10-17 01:35:58 UTC (rev 626=
4)
+++ trunk/coregrind/pub_core_debuginfo.h 2006-10-17 01:36:37 UTC (rev 626=
5)
@@ -39,18 +39,39 @@
=20
#include "pub_tool_debuginfo.h"
=20
-/* Notify the debuginfo system about a new mapping. This is the way
- new debug information gets loaded. If allow_SkFileV is True, it
- will try load debug info if the mapping at 'a' belongs to Valgrind;
- whereas normally (False) it will not do that. This allows us to
- carefully control when the thing will read symbols from the
- Valgrind executable itself. */
+/* LINUX: Notify the debuginfo system about a new mapping, or the
+ disappearance of such, or a permissions change on an existing
+ mapping. This is the way new debug information gets loaded. If
+ allow_SkFileV is True, it will try load debug info if the mapping
+ at 'a' belongs to Valgrind; whereas normally (False) it will not do
+ that. This allows us to carefully control when the thing will read
+ symbols from the Valgrind executable itself. */
+#if defined(VGO_linux)
extern void VG_(di_notify_mmap)( Addr a, Bool allow_SkFileV );
=20
extern void VG_(di_notify_munmap)( Addr a, SizeT len );
=20
extern void VG_(di_notify_mprotect)( Addr a, SizeT len, UInt prot );
+#endif
=20
+#if defined(VGO_aix5)
+/* AIX5: Very similar, except packaged more neatly. The supplied
+ parameters describe a code segment and its associated data segment,
+ that have recently been mapped in -- so we need to read debug info
+ for it -- or conversely, have recently been dumped, in which case
+ the relevant debug info has to be unloaded. */
+extern void VG_(di_aix5_notify_segchange)(=20
+ Addr code_start,
+ Word code_len,
+ Addr data_start,
+ Word data_len,
+ UChar* file_name,
+ UChar* mem_name,
+ Bool is_mainexe,
+ Bool acquire
+ );
+#endif
+
extern Bool VG_(get_fnname_nodemangle)( Addr a,=20
Char* fnname, Int n_fnname );
=20
@@ -72,6 +93,16 @@
extern
Bool VG_(get_fnname_Z_demangle_only) ( Addr a, Char* buf, Int nbuf );
=20
+/* Map a function name to its entry point and toc pointer. Is done by
+ sequential search of all symbol tables, so is very slow. To
+ mitigate the worst performance effects, you may specify a soname
+ pattern, and only objects matching that pattern are searched.
+ Therefore specify "*" to search all the objects. On TOC-afflicted
+ platforms, a symbol is deemed to be found only if it has a nonzero
+ TOC pointer. */
+extern
+Bool VG_(lookup_symbol_SLOW)(UChar* sopatt, UChar* name, Addr* pEnt, Add=
r* pToc);
+
#endif // __PUB_CORE_DEBUGINFO_H
=20
/*--------------------------------------------------------------------*/
Modified: trunk/include/pub_tool_debuginfo.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/include/pub_tool_debuginfo.h 2006-10-17 01:35:58 UTC (rev 6264)
+++ trunk/include/pub_tool_debuginfo.h 2006-10-17 01:36:37 UTC (rev 6265)
@@ -119,6 +119,7 @@
extern void VG_(seginfo_syms_getidx) ( const SegInfo *si,=20
Int idx,
/*OUT*/Addr* addr,
+ /*OUT*/Addr* tocptr,
/*OUT*/UInt* size,
/*OUT*/HChar** name );
=20
|