blob: 8df00b5f3d8421dcf0ba9592127854b3d55d0717 [file] [log] [blame]
njn43b9a8a2005-05-10 04:37:01 +00001
2/*--------------------------------------------------------------------*/
3/*--- The core/tool interface. pub_tool_tooliface.h ---*/
4/*--------------------------------------------------------------------*/
5
6/*
7 This file is part of Valgrind, a dynamic binary instrumentation
8 framework.
9
sewardjb3a1e4b2015-08-21 11:32:26 +000010 Copyright (C) 2000-2015 Julian Seward
njn43b9a8a2005-05-10 04:37:01 +000011 jseward@acm.org
12
13 This program is free software; you can redistribute it and/or
14 modify it under the terms of the GNU General Public License as
15 published by the Free Software Foundation; either version 2 of the
16 License, or (at your option) any later version.
17
18 This program is distributed in the hope that it will be useful, but
19 WITHOUT ANY WARRANTY; without even the implied warranty of
20 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
21 General Public License for more details.
22
23 You should have received a copy of the GNU General Public License
24 along with this program; if not, write to the Free Software
25 Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
26 02111-1307, USA.
27
28 The GNU General Public License is contained in the file COPYING.
29*/
30
31#ifndef __PUB_TOOL_TOOLIFACE_H
32#define __PUB_TOOL_TOOLIFACE_H
33
njnacd885a2005-05-16 20:40:51 +000034#include "pub_tool_errormgr.h" // for Error, Supp
njn0fc5cbd2006-10-18 21:50:26 +000035#include "libvex.h" // for all Vex stuff
njnacd885a2005-05-16 20:40:51 +000036
njn43b9a8a2005-05-10 04:37:01 +000037/* ------------------------------------------------------------------ */
38/* The interface version */
39
njn08ce7b32009-02-27 03:38:28 +000040/* Initialise tool. Must do the following:
41 - initialise the `details' struct, via the VG_(details_*)() functions
42 - register the basic tool functions, via VG_(basic_tool_funcs)().
43 May do the following:
44 - initialise the `needs' struct to indicate certain requirements, via
45 the VG_(needs_*)() functions
46 - any other tool-specific initialisation
47*/
48extern void (*VG_(tl_pre_clo_init)) ( void );
njn43b9a8a2005-05-10 04:37:01 +000049
njn08ce7b32009-02-27 03:38:28 +000050/* Every tool must include this macro somewhere, exactly once. The
51 interface version is no longer relevant, but we kept the same name
52 to avoid requiring changes to tools.
53*/
54#define VG_DETERMINE_INTERFACE_VERSION(pre_clo_init) \
55 void (*VG_(tl_pre_clo_init)) ( void ) = pre_clo_init;
njn43b9a8a2005-05-10 04:37:01 +000056
57/* ------------------------------------------------------------------ */
58/* Basic tool functions */
59
sewardj461df9c2006-01-17 02:06:39 +000060/* The tool_instrument function is passed as a callback to
sewardj7ce62392006-10-15 12:48:18 +000061 LibVEX_Translate. VgCallbackClosure carries additional info
sewardj461df9c2006-01-17 02:06:39 +000062 which the instrumenter might like to know, but which is opaque to
63 Vex.
64*/
65typedef
66 struct {
florianddd61ff2015-01-04 17:20:45 +000067 Addr nraddr; /* non-redirected guest address */
68 Addr readdr; /* redirected guest address */
sewardj461df9c2006-01-17 02:06:39 +000069 ThreadId tid; /* tid requesting translation */
70 }
71 VgCallbackClosure;
72
njn43b9a8a2005-05-10 04:37:01 +000073extern void VG_(basic_tool_funcs)(
74 // Do any initialisation that can only be done after command line
75 // processing.
76 void (*post_clo_init)(void),
77
sewardj4ba057c2005-10-18 12:04:18 +000078 // Instrument a basic block. Must be a true function, ie. the same
79 // input always results in the same output, because basic blocks
sewardj7ce62392006-10-15 12:48:18 +000080 // can be retranslated, unless you're doing something really
81 // strange. Anyway, the arguments. Mostly they are straightforward
82 // except for the distinction between redirected and non-redirected
83 // guest code addresses, which is important to understand.
84 //
85 // VgCallBackClosure* closure contains extra arguments passed
86 // from Valgrind to the instrumenter, which Vex doesn't know about.
87 // You are free to look inside this structure.
88 //
89 // * closure->tid is the ThreadId of the thread requesting the
90 // translation. Not sure why this is here; perhaps callgrind
91 // uses it.
92 //
93 // * closure->nraddr is the non-redirected guest address of the
94 // start of the translation. In other words, the translation is
95 // being constructed because the guest program jumped to
96 // closure->nraddr but no translation of it was found.
97 //
98 // * closure->readdr is the redirected guest address, from which
99 // the translation was really made.
100 //
101 // To clarify this, consider what happens when, in Memcheck, the
102 // first call to malloc() happens. The guest program will be
103 // trying to jump to malloc() in libc; hence ->nraddr will contain
104 // that address. However, Memcheck intercepts and replaces
105 // malloc, hence ->readdr will be the address of Memcheck's
106 // malloc replacement in
107 // coregrind/m_replacemalloc/vg_replacemalloc.c. It follows
108 // that the first IMark in the translation will be labelled as
109 // from ->readdr rather than ->nraddr.
110 //
111 // Since most functions are not redirected, the majority of the
112 // time ->nraddr will be the same as ->readdr. However, you
113 // cannot assume this: if your tool has metadata associated
114 // with code addresses it will get into deep trouble if it does
115 // make this assumption.
116 //
sewardj0b9d74a2006-12-24 02:24:11 +0000117 // IRSB* sb_in is the incoming superblock to be instrumented,
118 // in flat IR form.
sewardj7ce62392006-10-15 12:48:18 +0000119 //
120 // VexGuestLayout* layout contains limited info on the layout of
121 // the guest state: where the stack pointer and program counter
122 // are, and which fields should be regarded as 'always defined'.
123 // Memcheck uses this.
124 //
125 // VexGuestExtents* vge points to a structure which states the
126 // precise byte ranges of original code from which this translation
127 // was made (there may be up to three different ranges involved).
128 // Note again that these are the real addresses from which the code
129 // came. And so it should be the case that closure->readdr is the
130 // same as vge->base[0]; indeed Cachegrind contains this assertion.
131 //
132 // Tools which associate shadow data with code addresses
133 // (cachegrind, callgrind) need to be particularly clear about
134 // whether they are making the association with redirected or
135 // non-redirected code addresses. Both approaches are viable
136 // but you do need to understand what's going on. See comments
137 // below on discard_basic_block_info().
138 //
139 // IRType gWordTy and IRType hWordTy contain the types of native
140 // words on the guest (simulated) and host (real) CPUs. They will
141 // by either Ity_I32 or Ity_I64. So far we have never built a
142 // cross-architecture Valgrind so they should always be the same.
143 //
sewardjc87b5ec2006-10-15 13:46:18 +0000144 /* --- Further comments about the IR that your --- */
145 /* --- instrumentation function will receive. --- */
146 /*
njna3cc29f2007-02-05 23:23:55 +0000147 In the incoming IRSB, the IR for each instruction begins with an
sewardjc87b5ec2006-10-15 13:46:18 +0000148 IRStmt_IMark, which states the address and length of the
149 instruction from which this IR came. This makes it easy for
150 profiling-style tools to know precisely which guest code
151 addresses are being executed.
152
153 However, before the first IRStmt_IMark, there may be other IR
154 statements -- a preamble. In most cases this preamble is empty,
155 but when it isn't, what it contains is some supporting IR that
156 the JIT uses to ensure control flow works correctly. This
157 preamble does not modify any architecturally defined guest state
158 (registers or memory) and so does not contain anything that will
159 be of interest to your tool.
160
161 You should therefore
162
163 (1) copy any IR preceding the first IMark verbatim to the start
njna3cc29f2007-02-05 23:23:55 +0000164 of the output IRSB.
sewardjc87b5ec2006-10-15 13:46:18 +0000165
166 (2) not try to instrument it or modify it in any way.
167
168 For the record, stuff that may be in the preamble at
169 present is:
170
171 - A self-modifying-code check has been requested for this block.
172 The preamble will contain instructions to checksum the block,
173 compare against the expected value, and exit the dispatcher
174 requesting a discard (hence forcing a retranslation) if they
175 don't match.
176
177 - This block is known to be the entry point of a wrapper of some
sewardj358ebea2006-10-15 13:47:43 +0000178 function F. In this case the preamble contains code to write
sewardjc87b5ec2006-10-15 13:46:18 +0000179 the address of the original F (the fn being wrapped) into a
180 'hidden' guest state register _NRADDR. The wrapper can later
181 read this register using a client request and make a
182 non-redirected call to it using another client-request-like
183 magic macro.
184
185 - For platforms that use the AIX ABI (including ppc64-linux), it
sewardj358ebea2006-10-15 13:47:43 +0000186 is necessary to have a preamble even for replacement functions
187 (not just for wrappers), because it is necessary to switch the
188 R2 register (constant-pool pointer) to a different value when
189 swizzling the program counter.
sewardjc87b5ec2006-10-15 13:46:18 +0000190
191 Hence the preamble pushes both R2 and LR (the return address)
192 on a small 16-entry stack in the guest state and sets R2 to an
193 appropriate value for the wrapper/replacement fn. LR is then
194 set so that the wrapper/replacement fn returns to a magic IR
195 stub which restores R2 and LR and returns.
196
197 It's all hugely ugly and fragile. And it places a stringent
198 requirement on m_debuginfo to find out the correct R2 (toc
199 pointer) value for the wrapper/replacement function. So much
200 so that m_redir will refuse to honour a redirect-to-me request
201 if it cannot find (by asking m_debuginfo) a plausible R2 value
202 for 'me'.
203
204 Because this mechanism maintains a shadow stack of (R2,LR)
205 pairs in the guest state, it will fail if the
206 wrapper/redirection function, or anything it calls, longjumps
207 out past the wrapper, because then the magic return stub will
208 not be run and so the shadow stack will not be popped. So it
209 will quickly fill up. Fortunately none of this applies to
210 {x86,amd64,ppc32}-linux; on those platforms, wrappers can
211 longjump and recurse arbitrarily and everything should work
212 fine.
sewardjf1962d32006-10-19 13:22:16 +0000213
214 Note that copying the preamble verbatim may cause complications
215 for your instrumenter if you shadow IR temporaries. See big
216 comment in MC_(instrument) in memcheck/mc_translate.c for
217 details.
sewardjc87b5ec2006-10-15 13:46:18 +0000218 */
sewardj0b9d74a2006-12-24 02:24:11 +0000219 IRSB*(*instrument)(VgCallbackClosure* closure,
220 IRSB* sb_in,
florian3c0c9472014-09-24 12:06:55 +0000221 const VexGuestLayout* layout,
222 const VexGuestExtents* vge,
223 const VexArchInfo* archinfo_host,
sewardj7ce62392006-10-15 12:48:18 +0000224 IRType gWordTy,
225 IRType hWordTy),
njn43b9a8a2005-05-10 04:37:01 +0000226
227 // Finish up, print out any results, etc. `exitcode' is program's exit
228 // code. The shadow can be found with VG_(get_exit_status_shadow)().
229 void (*fini)(Int)
230);
231
232/* ------------------------------------------------------------------ */
233/* Details */
234
235/* Default value for avg_translations_sizeB (in bytes), indicating typical
236 code expansion of about 6:1. */
sewardj9644cfd2006-10-17 02:25:50 +0000237#define VG_DEFAULT_TRANS_SIZEB 172
njn43b9a8a2005-05-10 04:37:01 +0000238
239/* Information used in the startup message. `name' also determines the
240 string used for identifying suppressions in a suppression file as
241 belonging to this tool. `version' can be NULL, in which case (not
242 surprisingly) no version info is printed; this mechanism is designed for
243 tools distributed with Valgrind that share a version number with
244 Valgrind. Other tools not distributed as part of Valgrind should
245 probably have their own version number. */
florian2b8059a2012-10-14 16:45:23 +0000246extern void VG_(details_name) ( const HChar* name );
247extern void VG_(details_version) ( const HChar* version );
248extern void VG_(details_description) ( const HChar* description );
249extern void VG_(details_copyright_author) ( const HChar* copyright_author );
njn43b9a8a2005-05-10 04:37:01 +0000250
251/* Average size of a translation, in bytes, so that the translation
252 storage machinery can allocate memory appropriately. Not critical,
253 setting is optional. */
254extern void VG_(details_avg_translation_sizeB) ( UInt size );
255
256/* String printed if an `tl_assert' assertion fails or VG_(tool_panic)
257 is called. Should probably be an email address. */
florian2b8059a2012-10-14 16:45:23 +0000258extern void VG_(details_bug_reports_to) ( const HChar* bug_reports_to );
njn43b9a8a2005-05-10 04:37:01 +0000259
260/* ------------------------------------------------------------------ */
261/* Needs */
262
njn43b9a8a2005-05-10 04:37:01 +0000263/* Should __libc_freeres() be run? Bugs in it can crash the tool. */
264extern void VG_(needs_libc_freeres) ( void );
265
266/* Want to have errors detected by Valgrind's core reported? Includes:
njn0087c502005-07-01 04:15:36 +0000267 - pthread API errors (many; eg. unlocking a non-locked mutex)
268 [currently disabled]
269 - invalid file descriptors to syscalls like read() and write()
njn43b9a8a2005-05-10 04:37:01 +0000270 - bad signal numbers passed to sigaction()
271 - attempt to install signal handler for SIGKILL or SIGSTOP */
272extern void VG_(needs_core_errors) ( void );
273
274/* Booleans that indicate extra operations are defined; if these are True,
275 the corresponding template functions (given below) must be defined. A
276 lot like being a member of a type class. */
277
278/* Want to report errors from tool? This implies use of suppressions, too. */
279extern void VG_(needs_tool_errors) (
njna5453e92009-07-27 22:21:22 +0000280 // Identify if two errors are equal, or close enough. This function is
281 // only called if e1 and e2 will have the same error kind. `res' indicates
282 // how close is "close enough". `res' should be passed on as necessary,
283 // eg. if the Error's `extra' part contains an ExeContext, `res' should be
njn43b9a8a2005-05-10 04:37:01 +0000284 // passed to VG_(eq_ExeContext)() if the ExeContexts are considered. Other
285 // than that, probably don't worry about it unless you have lots of very
286 // similar errors occurring.
florian8e3fbb52014-10-20 19:02:38 +0000287 Bool (*eq_Error)(VgRes res, const Error* e1, const Error* e2),
njn43b9a8a2005-05-10 04:37:01 +0000288
sewardj5d9dc752009-07-15 14:52:18 +0000289 // We give tools a chance to have a look at errors
290 // just before they are printed. That is, before_pp_Error is
291 // called just before pp_Error itself. This gives the tool a
292 // chance to look at the just-about-to-be-printed error, so as to
293 // emit any arbitrary output if wants to, before the error itself
294 // is printed. This functionality was added to allow Helgrind to
295 // print thread-announcement messages immediately before the
296 // errors that refer to them.
florian8e3fbb52014-10-20 19:02:38 +0000297 void (*before_pp_Error)(const Error* err),
sewardj5d9dc752009-07-15 14:52:18 +0000298
njn43b9a8a2005-05-10 04:37:01 +0000299 // Print error context.
florian8e3fbb52014-10-20 19:02:38 +0000300 void (*pp_Error)(const Error* err),
njn43b9a8a2005-05-10 04:37:01 +0000301
sewardjadb102f2007-11-09 23:21:44 +0000302 // Should the core indicate which ThreadId each error comes from?
303 Bool show_ThreadIDs_for_errors,
304
njn43b9a8a2005-05-10 04:37:01 +0000305 // Should fill in any details that could be postponed until after the
306 // decision whether to ignore the error (ie. details not affecting the
307 // result of VG_(tdict).tool_eq_Error()). This saves time when errors
308 // are ignored.
309 // Yuk.
310 // Return value: must be the size of the `extra' part in bytes -- used by
311 // the core to make a copy.
florian8e3fbb52014-10-20 19:02:38 +0000312 UInt (*update_extra)(const Error* err),
njn43b9a8a2005-05-10 04:37:01 +0000313
314 // Return value indicates recognition. If recognised, must set skind using
315 // VG_(set_supp_kind)().
florian19f91bb2012-11-10 22:29:54 +0000316 Bool (*recognised_suppression)(const HChar* name, Supp* su),
njn43b9a8a2005-05-10 04:37:01 +0000317
318 // Read any extra info for this suppression kind. Most likely for filling
319 // in the `extra' and `string' parts (with VG_(set_supp_{extra, string})())
320 // of a suppression if necessary. Should return False if a syntax error
philippe362441d2013-07-22 22:00:13 +0000321 // occurred, True otherwise.
322 // fd, bufpp, nBufp and lineno are the same as for VG_(get_line).
florian19f91bb2012-11-10 22:29:54 +0000323 Bool (*read_extra_suppression_info)(Int fd, HChar** bufpp, SizeT* nBufp,
philippe362441d2013-07-22 22:00:13 +0000324 Int* lineno, Supp* su),
njn43b9a8a2005-05-10 04:37:01 +0000325
326 // This should just check the kinds match and maybe some stuff in the
327 // `string' and `extra' field if appropriate (using VG_(get_supp_*)() to
328 // get the relevant suppression parts).
florian8e3fbb52014-10-20 19:02:38 +0000329 Bool (*error_matches_suppression)(const Error* err, const Supp* su),
njn43b9a8a2005-05-10 04:37:01 +0000330
331 // This should return the suppression name, for --gen-suppressions, or NULL
332 // if that error type cannot be suppressed. This is the inverse of
333 // VG_(tdict).tool_recognised_suppression().
florian8e3fbb52014-10-20 19:02:38 +0000334 const HChar* (*get_error_name)(const Error* err),
njn43b9a8a2005-05-10 04:37:01 +0000335
sewardj588adef2009-08-15 22:41:51 +0000336 // This should print into buf[0..nBuf-1] any extra info for the
337 // error, for --gen-suppressions, but not including any leading
florian3e81b8b2014-10-07 14:28:52 +0000338 // spaces nor a trailing newline. The string needs to be null
339 // terminated. If the buffer is large enough to hold the string
340 // including the terminating null character the function shall
341 // return the value that strlen would return for the string.
342 // If the buffer is too small the function shall return nBuf.
florian8e3fbb52014-10-20 19:02:38 +0000343 SizeT (*print_extra_suppression_info)(const Error* err,
florian3e81b8b2014-10-07 14:28:52 +0000344 /*OUT*/HChar* buf, Int nBuf),
philippe4e32d672013-10-17 22:10:41 +0000345
346 // This is similar to print_extra_suppression_info, but is used
347 // to print information such as additional statistical counters
348 // as part of the used suppression list produced by -v.
florian8e3fbb52014-10-20 19:02:38 +0000349 SizeT (*print_extra_suppression_use)(const Supp* su,
florian3e81b8b2014-10-07 14:28:52 +0000350 /*OUT*/HChar* buf, Int nBuf),
philippe4e32d672013-10-17 22:10:41 +0000351
352 // Called by error mgr once it has been established that err
353 // is suppressed by su. update_extra_suppression_use typically
354 // can be used to update suppression extra information such as
355 // some statistical counters that will be printed by
356 // print_extra_suppression_use.
florian8e3fbb52014-10-20 19:02:38 +0000357 void (*update_extra_suppression_use)(const Error* err, const Supp* su)
njn43b9a8a2005-05-10 04:37:01 +0000358);
359
sewardj5155dec2005-10-12 10:09:23 +0000360/* Is information kept by the tool about specific instructions or
361 translations? (Eg. for cachegrind there are cost-centres for every
362 instruction, stored in a per-translation fashion.) If so, the info
363 may have to be discarded when translations are unloaded (eg. due to
364 .so unloading, or otherwise at the discretion of m_transtab, eg
365 when the table becomes too full) to avoid stale information being
366 reused for new translations. */
sewardj0b9d74a2006-12-24 02:24:11 +0000367extern void VG_(needs_superblock_discards) (
sewardj5155dec2005-10-12 10:09:23 +0000368 // Discard any information that pertains to specific translations
sewardj4ba057c2005-10-18 12:04:18 +0000369 // or instructions within the address range given. There are two
370 // possible approaches.
371 // - If info is being stored at a per-translation level, use orig_addr
372 // to identify which translation is being discarded. Each translation
373 // will be discarded exactly once.
sewardj7ce62392006-10-15 12:48:18 +0000374 // This orig_addr will match the closure->nraddr which was passed to
375 // to instrument() (see extensive comments above) when this
376 // translation was made. Note that orig_addr won't necessarily be
377 // the same as the first address in "extents".
sewardj5155dec2005-10-12 10:09:23 +0000378 // - If info is being stored at a per-instruction level, you can get
379 // the address range(s) being discarded by stepping through "extents".
380 // Note that any single instruction may belong to more than one
381 // translation, and so could be covered by the "extents" of more than
382 // one call to this function.
383 // Doing it the first way (as eg. Cachegrind does) is probably easier.
florianddd61ff2015-01-04 17:20:45 +0000384 void (*discard_superblock_info)(Addr orig_addr, VexGuestExtents extents)
njn43b9a8a2005-05-10 04:37:01 +0000385);
386
387/* Tool defines its own command line options? */
388extern void VG_(needs_command_line_options) (
njnb1cc5d62010-07-06 04:05:23 +0000389 // Return True if option was recognised, False if it wasn't (but also see
390 // below). Presumably sets some state to record the option as well.
391 //
392 // Nb: tools can assume that the argv will never disappear. So they can,
393 // for example, store a pointer to a string within an option, rather than
394 // having to make a copy.
395 //
396 // Options (and combinations of options) should be checked in this function
397 // if possible rather than in post_clo_init(), and if they are bad then
398 // VG_(fmsg_bad_option)() should be called. This ensures that the
399 // messaging is consistent with command line option errors from the core.
florian19f91bb2012-11-10 22:29:54 +0000400 Bool (*process_cmd_line_option)(const HChar* argv),
njn43b9a8a2005-05-10 04:37:01 +0000401
402 // Print out command line usage for options for normal tool operation.
403 void (*print_usage)(void),
404
405 // Print out command line usage for options for debugging the tool.
406 void (*print_debug_usage)(void)
407);
408
409/* Tool defines its own client requests? */
410extern void VG_(needs_client_requests) (
411 // If using client requests, the number of the first request should be equal
412 // to VG_USERREQ_TOOL_BASE('X', 'Y'), where 'X' and 'Y' form a suitable two
413 // character identification for the string. The second and subsequent
414 // requests should follow.
415 //
416 // This function should use the VG_IS_TOOL_USERREQ macro (in
417 // include/valgrind.h) to first check if it's a request for this tool. Then
418 // should handle it if it's recognised (and return True), or return False if
419 // not recognised. arg_block[0] holds the request number, any further args
420 // from the request are in arg_block[1..]. 'ret' is for the return value...
421 // it should probably be filled, if only with 0.
422 Bool (*handle_client_request)(ThreadId tid, UWord* arg_block, UWord* ret)
423);
424
425/* Tool does stuff before and/or after system calls? */
426// Nb: If either of the pre_ functions malloc() something to return, the
427// corresponding post_ function had better free() it!
sewardj1c0ce7a2009-07-01 08:10:49 +0000428// Also, the args are the 'original args' -- that is, it may be
429// that the syscall pre-wrapper will modify the args before the
430// syscall happens. So these args are the original, un-modified
431// args. Finally, nArgs merely indicates the length of args[..],
432// it does not indicate how many of those values are actually
433// relevant to the syscall. args[0 .. nArgs-1] is guaranteed
434// to be defined and to contain all the args for this syscall,
435// possibly including some trailing zeroes.
njn43b9a8a2005-05-10 04:37:01 +0000436extern void VG_(needs_syscall_wrapper) (
sewardj1c0ce7a2009-07-01 08:10:49 +0000437 void (* pre_syscall)(ThreadId tid, UInt syscallno,
438 UWord* args, UInt nArgs),
439 void (*post_syscall)(ThreadId tid, UInt syscallno,
440 UWord* args, UInt nArgs, SysRes res)
njn43b9a8a2005-05-10 04:37:01 +0000441);
442
443/* Are tool-state sanity checks performed? */
444// Can be useful for ensuring a tool's correctness. cheap_sanity_check()
445// is called very frequently; expensive_sanity_check() is called less
446// frequently and can be more involved.
447extern void VG_(needs_sanity_checks) (
448 Bool(*cheap_sanity_check)(void),
449 Bool(*expensive_sanity_check)(void)
450);
451
philippe8587b542013-12-15 20:24:43 +0000452/* Can the tool produce stats during execution? */
453extern void VG_(needs_print_stats) (
454 // Print out tool status. Note that the stats at end of execution
455 // should be output by the VG_(basic_tool_funcs) "fini" function.
456 void (*print_stats)(void)
457);
458
philippe07c08522014-05-14 20:39:27 +0000459/* Has the tool a tool specific function to retrieve and print location info
460 of an address ? */
461extern void VG_(needs_info_location) (
462 // Get and pp information about Addr
463 void (*info_location)(Addr)
464);
465
sewardjb8b79ad2008-03-03 01:35:41 +0000466/* Do we need to see variable type and location information? */
467extern void VG_(needs_var_info) ( void );
njn43b9a8a2005-05-10 04:37:01 +0000468
njn09ca09b2005-10-16 17:48:09 +0000469/* Does the tool replace malloc() and friends with its own versions?
470 This has to be combined with the use of a vgpreload_<tool>.so module
471 or it won't work. See massif/Makefile.am for how to build it. */
njn43b9a8a2005-05-10 04:37:01 +0000472// The 'p' prefix avoids GCC complaints about overshadowing global names.
njnfc51f8d2005-06-21 03:20:17 +0000473extern void VG_(needs_malloc_replacement)(
njn43b9a8a2005-05-10 04:37:01 +0000474 void* (*pmalloc) ( ThreadId tid, SizeT n ),
475 void* (*p__builtin_new) ( ThreadId tid, SizeT n ),
476 void* (*p__builtin_vec_new) ( ThreadId tid, SizeT n ),
477 void* (*pmemalign) ( ThreadId tid, SizeT align, SizeT n ),
478 void* (*pcalloc) ( ThreadId tid, SizeT nmemb, SizeT size1 ),
479 void (*pfree) ( ThreadId tid, void* p ),
480 void (*p__builtin_delete) ( ThreadId tid, void* p ),
481 void (*p__builtin_vec_delete) ( ThreadId tid, void* p ),
482 void* (*prealloc) ( ThreadId tid, void* p, SizeT new_size ),
njn8b140de2009-02-17 04:31:18 +0000483 SizeT (*pmalloc_usable_size) ( ThreadId tid, void* p),
njn43b9a8a2005-05-10 04:37:01 +0000484 SizeT client_malloc_redzone_szB
485);
486
njnca54af32006-04-16 10:25:43 +0000487/* Can the tool do XML output? This is a slight misnomer, because the tool
488 * is not requesting the core to do anything, rather saying "I can handle
489 * it". */
sewardj5d9dc752009-07-15 14:52:18 +0000490extern void VG_(needs_xml_output) ( void );
njnca54af32006-04-16 10:25:43 +0000491
sewardj81651dc2007-08-28 06:05:20 +0000492/* Does the tool want to have one final pass over the IR after tree
493 building but before instruction selection? If so specify the
494 function here. */
495extern void VG_(needs_final_IR_tidy_pass) ( IRSB*(*final_tidy)(IRSB*) );
496
497
njn43b9a8a2005-05-10 04:37:01 +0000498/* ------------------------------------------------------------------ */
499/* Core events to track */
500
501/* Part of the core from which this call was made. Useful for determining
502 what kind of error message should be emitted. */
503typedef
sewardj9c606bd2008-09-18 18:12:50 +0000504 enum { Vg_CoreStartup=1, Vg_CoreSignal, Vg_CoreSysCall,
njnf76d27a2009-05-28 01:53:07 +0000505 // This is for platforms where syscall args are passed on the
506 // stack; although pre_mem_read is the callback that will be
507 // called, such an arg should be treated (with respect to
508 // presenting information to the user) as if it was passed in a
509 // register, ie. like pre_reg_read.
510 Vg_CoreSysCallArgInMem,
511 Vg_CoreTranslate, Vg_CoreClientReq
512 } CorePart;
njn43b9a8a2005-05-10 04:37:01 +0000513
514/* Events happening in core to track. To be notified, pass a callback
515 function to the appropriate function. To ignore an event, don't do
516 anything (the default is for events to be ignored).
517
518 Note that most events aren't passed a ThreadId. If the event is one called
519 from generated code (eg. new_mem_stack_*), you can use
520 VG_(get_running_tid)() to find it. Otherwise, it has to be passed in,
521 as in pre_mem_read, and so the event signature will require changing.
522
523 Memory events (Nb: to track heap allocation/freeing, a tool must replace
524 malloc() et al. See above how to do this.)
525
sewardj7cf4e6b2008-05-01 20:24:26 +0000526 These ones occur at startup, upon some signals, and upon some syscalls.
527
sewardj9c606bd2008-09-18 18:12:50 +0000528 For new_mem_brk and new_mem_stack_signal, the supplied ThreadId
sewardj7cf4e6b2008-05-01 20:24:26 +0000529 indicates the thread for whom the new memory is being allocated.
sewardj9c606bd2008-09-18 18:12:50 +0000530
531 For new_mem_startup and new_mem_mmap, the di_handle argument is a
532 handle which can be used to retrieve debug info associated with the
533 mapping or allocation (because it is of a file that Valgrind has
534 decided to read debug info from). If the value is zero, there is
535 no associated debug info. If the value exceeds zero, it can be
536 supplied as an argument to selected queries in m_debuginfo.
sewardj7cf4e6b2008-05-01 20:24:26 +0000537*/
njn43b9a8a2005-05-10 04:37:01 +0000538void VG_(track_new_mem_startup) (void(*f)(Addr a, SizeT len,
sewardj9c606bd2008-09-18 18:12:50 +0000539 Bool rr, Bool ww, Bool xx,
540 ULong di_handle));
sewardj7cf4e6b2008-05-01 20:24:26 +0000541void VG_(track_new_mem_stack_signal)(void(*f)(Addr a, SizeT len, ThreadId tid));
542void VG_(track_new_mem_brk) (void(*f)(Addr a, SizeT len, ThreadId tid));
njn43b9a8a2005-05-10 04:37:01 +0000543void VG_(track_new_mem_mmap) (void(*f)(Addr a, SizeT len,
sewardj9c606bd2008-09-18 18:12:50 +0000544 Bool rr, Bool ww, Bool xx,
545 ULong di_handle));
njn43b9a8a2005-05-10 04:37:01 +0000546
547void VG_(track_copy_mem_remap) (void(*f)(Addr from, Addr to, SizeT len));
548void VG_(track_change_mem_mprotect) (void(*f)(Addr a, SizeT len,
549 Bool rr, Bool ww, Bool xx));
550void VG_(track_die_mem_stack_signal)(void(*f)(Addr a, SizeT len));
551void VG_(track_die_mem_brk) (void(*f)(Addr a, SizeT len));
552void VG_(track_die_mem_munmap) (void(*f)(Addr a, SizeT len));
553
554/* These ones are called when SP changes. A tool could track these itself
555 (except for ban_mem_stack) but it's much easier to use the core's help.
556
557 The specialised ones are called in preference to the general one, if they
558 are defined. These functions are called a lot if they are used, so
559 specialising can optimise things significantly. If any of the
560 specialised cases are defined, the general case must be defined too.
561
njnaf839f52005-06-23 03:27:57 +0000562 Nb: all the specialised ones must use the VG_REGPARM(n) attribute.
sewardj7cf4e6b2008-05-01 20:24:26 +0000563
564 For the _new functions, a tool may specify with with-ECU
565 (ExeContext Unique) or without-ECU version for each size, but not
566 both. If the with-ECU version is supplied, then the core will
567 arrange to pass, as the ecu argument, a 32-bit int which uniquely
568 identifies the instruction moving the stack pointer down. This
569 32-bit value is as obtained from VG_(get_ECU_from_ExeContext).
570 VG_(get_ExeContext_from_ECU) can then be used to retrieve the
571 associated depth-1 ExeContext for the location. All this
572 complexity is provided to support origin tracking in Memcheck.
573*/
574void VG_(track_new_mem_stack_4_w_ECU) (VG_REGPARM(2) void(*f)(Addr new_ESP, UInt ecu));
575void VG_(track_new_mem_stack_8_w_ECU) (VG_REGPARM(2) void(*f)(Addr new_ESP, UInt ecu));
576void VG_(track_new_mem_stack_12_w_ECU) (VG_REGPARM(2) void(*f)(Addr new_ESP, UInt ecu));
577void VG_(track_new_mem_stack_16_w_ECU) (VG_REGPARM(2) void(*f)(Addr new_ESP, UInt ecu));
578void VG_(track_new_mem_stack_32_w_ECU) (VG_REGPARM(2) void(*f)(Addr new_ESP, UInt ecu));
579void VG_(track_new_mem_stack_112_w_ECU)(VG_REGPARM(2) void(*f)(Addr new_ESP, UInt ecu));
580void VG_(track_new_mem_stack_128_w_ECU)(VG_REGPARM(2) void(*f)(Addr new_ESP, UInt ecu));
581void VG_(track_new_mem_stack_144_w_ECU)(VG_REGPARM(2) void(*f)(Addr new_ESP, UInt ecu));
582void VG_(track_new_mem_stack_160_w_ECU)(VG_REGPARM(2) void(*f)(Addr new_ESP, UInt ecu));
583void VG_(track_new_mem_stack_w_ECU) (void(*f)(Addr a, SizeT len,
584 UInt ecu));
585
sewardjf5c8e372006-02-12 15:42:20 +0000586void VG_(track_new_mem_stack_4) (VG_REGPARM(1) void(*f)(Addr new_ESP));
587void VG_(track_new_mem_stack_8) (VG_REGPARM(1) void(*f)(Addr new_ESP));
588void VG_(track_new_mem_stack_12) (VG_REGPARM(1) void(*f)(Addr new_ESP));
589void VG_(track_new_mem_stack_16) (VG_REGPARM(1) void(*f)(Addr new_ESP));
590void VG_(track_new_mem_stack_32) (VG_REGPARM(1) void(*f)(Addr new_ESP));
591void VG_(track_new_mem_stack_112)(VG_REGPARM(1) void(*f)(Addr new_ESP));
592void VG_(track_new_mem_stack_128)(VG_REGPARM(1) void(*f)(Addr new_ESP));
593void VG_(track_new_mem_stack_144)(VG_REGPARM(1) void(*f)(Addr new_ESP));
594void VG_(track_new_mem_stack_160)(VG_REGPARM(1) void(*f)(Addr new_ESP));
595void VG_(track_new_mem_stack) (void(*f)(Addr a, SizeT len));
njn43b9a8a2005-05-10 04:37:01 +0000596
sewardjf5c8e372006-02-12 15:42:20 +0000597void VG_(track_die_mem_stack_4) (VG_REGPARM(1) void(*f)(Addr die_ESP));
598void VG_(track_die_mem_stack_8) (VG_REGPARM(1) void(*f)(Addr die_ESP));
599void VG_(track_die_mem_stack_12) (VG_REGPARM(1) void(*f)(Addr die_ESP));
600void VG_(track_die_mem_stack_16) (VG_REGPARM(1) void(*f)(Addr die_ESP));
601void VG_(track_die_mem_stack_32) (VG_REGPARM(1) void(*f)(Addr die_ESP));
602void VG_(track_die_mem_stack_112)(VG_REGPARM(1) void(*f)(Addr die_ESP));
603void VG_(track_die_mem_stack_128)(VG_REGPARM(1) void(*f)(Addr die_ESP));
604void VG_(track_die_mem_stack_144)(VG_REGPARM(1) void(*f)(Addr die_ESP));
605void VG_(track_die_mem_stack_160)(VG_REGPARM(1) void(*f)(Addr die_ESP));
606void VG_(track_die_mem_stack) (void(*f)(Addr a, SizeT len));
njn43b9a8a2005-05-10 04:37:01 +0000607
608/* Used for redzone at end of thread stacks */
609void VG_(track_ban_mem_stack) (void(*f)(Addr a, SizeT len));
610
611/* These ones occur around syscalls, signal handling, etc */
612void VG_(track_pre_mem_read) (void(*f)(CorePart part, ThreadId tid,
floriane543f302012-10-21 19:43:43 +0000613 const HChar* s, Addr a, SizeT size));
njn43b9a8a2005-05-10 04:37:01 +0000614void VG_(track_pre_mem_read_asciiz)(void(*f)(CorePart part, ThreadId tid,
floriane543f302012-10-21 19:43:43 +0000615 const HChar* s, Addr a));
njn43b9a8a2005-05-10 04:37:01 +0000616void VG_(track_pre_mem_write) (void(*f)(CorePart part, ThreadId tid,
floriane543f302012-10-21 19:43:43 +0000617 const HChar* s, Addr a, SizeT size));
njn43b9a8a2005-05-10 04:37:01 +0000618void VG_(track_post_mem_write) (void(*f)(CorePart part, ThreadId tid,
619 Addr a, SizeT size));
620
621/* Register events. Use VG_(set_shadow_state_area)() to set the shadow regs
622 for these events. */
623void VG_(track_pre_reg_read) (void(*f)(CorePart part, ThreadId tid,
floriane543f302012-10-21 19:43:43 +0000624 const HChar* s, PtrdiffT guest_state_offset,
njn43b9a8a2005-05-10 04:37:01 +0000625 SizeT size));
626void VG_(track_post_reg_write)(void(*f)(CorePart part, ThreadId tid,
njnc4431bf2009-01-15 21:29:24 +0000627 PtrdiffT guest_state_offset,
njn43b9a8a2005-05-10 04:37:01 +0000628 SizeT size));
629
630/* This one is called for malloc() et al if they are replaced by a tool. */
631void VG_(track_post_reg_write_clientcall_return)(
njnc4431bf2009-01-15 21:29:24 +0000632 void(*f)(ThreadId tid, PtrdiffT guest_state_offset, SizeT size, Addr f));
njn43b9a8a2005-05-10 04:37:01 +0000633
sewardj8eb8bab2015-07-21 14:44:28 +0000634/* Mem-to-reg or reg-to-mem copy functions, these ones occur around syscalls
635 and signal handling when the VCPU state is saved to (or restored from) the
636 client memory. */
637void VG_(track_copy_mem_to_reg)(void(*f)(CorePart part, ThreadId tid,
638 Addr a, PtrdiffT guest_state_offset,
639 SizeT size));
640void VG_(track_copy_reg_to_mem)(void(*f)(CorePart part, ThreadId tid,
641 PtrdiffT guest_state_offset,
642 Addr a, SizeT size));
643
njn43b9a8a2005-05-10 04:37:01 +0000644
645/* Scheduler events (not exhaustive) */
sewardj97561812006-12-23 01:21:12 +0000646
647/* Called when 'tid' starts or stops running client code blocks.
sewardjadb102f2007-11-09 23:21:44 +0000648 Gives the total dispatched block count at that event. Note, this
649 is not the same as 'tid' holding the BigLock (the lock that ensures
650 that only one thread runs at a time): a thread can hold the lock
651 for other purposes (making translations, etc) yet not be running
652 client blocks. Obviously though, a thread must hold the lock in
653 order to run client code blocks, so the times bracketed by
654 'start_client_code'..'stop_client_code' are a subset of the times
655 when thread 'tid' holds the cpu lock.
sewardj97561812006-12-23 01:21:12 +0000656*/
njn3e32c872006-12-24 07:51:17 +0000657void VG_(track_start_client_code)(
658 void(*f)(ThreadId tid, ULong blocks_dispatched)
659 );
660void VG_(track_stop_client_code)(
661 void(*f)(ThreadId tid, ULong blocks_dispatched)
sewardj97561812006-12-23 01:21:12 +0000662 );
njn43b9a8a2005-05-10 04:37:01 +0000663
664
665/* Thread events (not exhaustive)
666
sewardjadb102f2007-11-09 23:21:44 +0000667 ll_create: low level thread creation. Called before the new thread
668 has run any instructions (or touched any memory). In fact, called
669 immediately before the new thread has come into existence; the new
670 thread can be assumed to exist when notified by this call.
671
672 ll_exit: low level thread exit. Called after the exiting thread
673 has run its last instruction.
sewardj29d68f72007-11-10 22:13:03 +0000674
675 The _ll_ part makes it clear these events are not to do with
676 pthread_create or pthread_exit/pthread_join (etc), which are a
sewardj391ddf82007-11-10 22:19:42 +0000677 higher level abstraction synthesised by libpthread. What you can
678 be sure of from _ll_create/_ll_exit is the absolute limits of each
sewardj29d68f72007-11-10 22:13:03 +0000679 thread's lifetime, and hence be assured that all memory references
680 made by the thread fall inside the _ll_create/_ll_exit pair. This
681 is important for tools that need a 100% accurate account of which
682 thread is responsible for every memory reference in the process.
683
sewardj391ddf82007-11-10 22:19:42 +0000684 pthread_create/join/exit do not give this property. Calls/returns
685 to/from them happen arbitrarily far away from the relevant
686 low-level thread create/quit event. In general a few hundred
687 instructions; hence a few hundred(ish) memory references could get
688 misclassified each time.
sewardj7a387ea2007-11-25 14:06:06 +0000689
690 pre_thread_first_insn: is called when the thread is all set up and
691 ready to go (stack in place, etc) but has not executed its first
692 instruction yet. Gives threading tools a chance to ask questions
693 about the thread (eg, what is its initial client stack pointer)
694 that are not easily answered at pre_thread_ll_create time.
695
696 For a given thread, the call sequence is:
697 ll_create (in the parent's context)
698 first_insn (in the child's context)
699 ll_exit (in the child's context)
sewardjadb102f2007-11-09 23:21:44 +0000700*/
sewardj7a387ea2007-11-25 14:06:06 +0000701void VG_(track_pre_thread_ll_create) (void(*f)(ThreadId tid, ThreadId child));
702void VG_(track_pre_thread_first_insn)(void(*f)(ThreadId tid));
703void VG_(track_pre_thread_ll_exit) (void(*f)(ThreadId tid));
njn43b9a8a2005-05-10 04:37:01 +0000704
njn3e32c872006-12-24 07:51:17 +0000705
njn43b9a8a2005-05-10 04:37:01 +0000706/* Signal events (not exhaustive)
707
708 ... pre_send_signal, post_send_signal ...
709
710 Called before a signal is delivered; `alt_stack' indicates if it is
711 delivered on an alternative stack. */
712void VG_(track_pre_deliver_signal) (void(*f)(ThreadId tid, Int sigNo,
713 Bool alt_stack));
714/* Called after a signal is delivered. Nb: unfortunately, if the signal
715 handler longjmps, this won't be called. */
716void VG_(track_post_deliver_signal)(void(*f)(ThreadId tid, Int sigNo));
717
njn43b9a8a2005-05-10 04:37:01 +0000718#endif // __PUB_TOOL_TOOLIFACE_H
719
720/*--------------------------------------------------------------------*/
721/*--- end ---*/
722/*--------------------------------------------------------------------*/