blob: f2012dcbfb6454d1d47732c0dce25d97a19bbd06 [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
sewardj9ebd6e02007-01-08 06:01:59 +000010 Copyright (C) 2000-2007 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
40/* The version number indicates binary-incompatible changes to the
41 interface; if the core and tool versions don't match, Valgrind
42 will abort. */
dirkf8126e92006-11-14 14:32:46 +000043#define VG_CORE_INTERFACE_VERSION 10
njn43b9a8a2005-05-10 04:37:01 +000044
45typedef struct _ToolInfo {
46 Int sizeof_ToolInfo;
47 Int interface_version;
48
49 /* Initialise tool. Must do the following:
50 - initialise the `details' struct, via the VG_(details_*)() functions
51 - register any helpers called by generated code
52
53 May do the following:
54 - initialise the `needs' struct to indicate certain requirements, via
55 the VG_(needs_*)() functions
56 - initialize all the tool's entrypoints via the VG_(init_*)() functions
57 - register any tool-specific profiling events
58 - any other tool-specific initialisation
59 */
60 void (*tl_pre_clo_init) ( void );
njn43b9a8a2005-05-10 04:37:01 +000061} ToolInfo;
62
sewardj45f4e7c2005-09-27 19:20:21 +000063extern const ToolInfo VG_(tool_info);
64
njn43b9a8a2005-05-10 04:37:01 +000065/* Every tool must include this macro somewhere, exactly once. */
sewardj45f4e7c2005-09-27 19:20:21 +000066#define VG_DETERMINE_INTERFACE_VERSION(pre_clo_init) \
njn43b9a8a2005-05-10 04:37:01 +000067 const ToolInfo VG_(tool_info) = { \
68 .sizeof_ToolInfo = sizeof(ToolInfo), \
69 .interface_version = VG_CORE_INTERFACE_VERSION, \
70 .tl_pre_clo_init = pre_clo_init, \
njn43b9a8a2005-05-10 04:37:01 +000071 };
72
73/* ------------------------------------------------------------------ */
74/* Basic tool functions */
75
sewardj461df9c2006-01-17 02:06:39 +000076/* The tool_instrument function is passed as a callback to
sewardj7ce62392006-10-15 12:48:18 +000077 LibVEX_Translate. VgCallbackClosure carries additional info
sewardj461df9c2006-01-17 02:06:39 +000078 which the instrumenter might like to know, but which is opaque to
79 Vex.
80*/
81typedef
82 struct {
83 Addr64 nraddr; /* non-redirected guest address */
84 Addr64 readdr; /* redirected guest address */
85 ThreadId tid; /* tid requesting translation */
86 }
87 VgCallbackClosure;
88
njn43b9a8a2005-05-10 04:37:01 +000089extern void VG_(basic_tool_funcs)(
90 // Do any initialisation that can only be done after command line
91 // processing.
92 void (*post_clo_init)(void),
93
sewardj4ba057c2005-10-18 12:04:18 +000094 // Instrument a basic block. Must be a true function, ie. the same
95 // input always results in the same output, because basic blocks
sewardj7ce62392006-10-15 12:48:18 +000096 // can be retranslated, unless you're doing something really
97 // strange. Anyway, the arguments. Mostly they are straightforward
98 // except for the distinction between redirected and non-redirected
99 // guest code addresses, which is important to understand.
100 //
101 // VgCallBackClosure* closure contains extra arguments passed
102 // from Valgrind to the instrumenter, which Vex doesn't know about.
103 // You are free to look inside this structure.
104 //
105 // * closure->tid is the ThreadId of the thread requesting the
106 // translation. Not sure why this is here; perhaps callgrind
107 // uses it.
108 //
109 // * closure->nraddr is the non-redirected guest address of the
110 // start of the translation. In other words, the translation is
111 // being constructed because the guest program jumped to
112 // closure->nraddr but no translation of it was found.
113 //
114 // * closure->readdr is the redirected guest address, from which
115 // the translation was really made.
116 //
117 // To clarify this, consider what happens when, in Memcheck, the
118 // first call to malloc() happens. The guest program will be
119 // trying to jump to malloc() in libc; hence ->nraddr will contain
120 // that address. However, Memcheck intercepts and replaces
121 // malloc, hence ->readdr will be the address of Memcheck's
122 // malloc replacement in
123 // coregrind/m_replacemalloc/vg_replacemalloc.c. It follows
124 // that the first IMark in the translation will be labelled as
125 // from ->readdr rather than ->nraddr.
126 //
127 // Since most functions are not redirected, the majority of the
128 // time ->nraddr will be the same as ->readdr. However, you
129 // cannot assume this: if your tool has metadata associated
130 // with code addresses it will get into deep trouble if it does
131 // make this assumption.
132 //
sewardj0b9d74a2006-12-24 02:24:11 +0000133 // IRSB* sb_in is the incoming superblock to be instrumented,
134 // in flat IR form.
sewardj7ce62392006-10-15 12:48:18 +0000135 //
136 // VexGuestLayout* layout contains limited info on the layout of
137 // the guest state: where the stack pointer and program counter
138 // are, and which fields should be regarded as 'always defined'.
139 // Memcheck uses this.
140 //
141 // VexGuestExtents* vge points to a structure which states the
142 // precise byte ranges of original code from which this translation
143 // was made (there may be up to three different ranges involved).
144 // Note again that these are the real addresses from which the code
145 // came. And so it should be the case that closure->readdr is the
146 // same as vge->base[0]; indeed Cachegrind contains this assertion.
147 //
148 // Tools which associate shadow data with code addresses
149 // (cachegrind, callgrind) need to be particularly clear about
150 // whether they are making the association with redirected or
151 // non-redirected code addresses. Both approaches are viable
152 // but you do need to understand what's going on. See comments
153 // below on discard_basic_block_info().
154 //
155 // IRType gWordTy and IRType hWordTy contain the types of native
156 // words on the guest (simulated) and host (real) CPUs. They will
157 // by either Ity_I32 or Ity_I64. So far we have never built a
158 // cross-architecture Valgrind so they should always be the same.
159 //
sewardjc87b5ec2006-10-15 13:46:18 +0000160 /* --- Further comments about the IR that your --- */
161 /* --- instrumentation function will receive. --- */
162 /*
njna3cc29f2007-02-05 23:23:55 +0000163 In the incoming IRSB, the IR for each instruction begins with an
sewardjc87b5ec2006-10-15 13:46:18 +0000164 IRStmt_IMark, which states the address and length of the
165 instruction from which this IR came. This makes it easy for
166 profiling-style tools to know precisely which guest code
167 addresses are being executed.
168
169 However, before the first IRStmt_IMark, there may be other IR
170 statements -- a preamble. In most cases this preamble is empty,
171 but when it isn't, what it contains is some supporting IR that
172 the JIT uses to ensure control flow works correctly. This
173 preamble does not modify any architecturally defined guest state
174 (registers or memory) and so does not contain anything that will
175 be of interest to your tool.
176
177 You should therefore
178
179 (1) copy any IR preceding the first IMark verbatim to the start
njna3cc29f2007-02-05 23:23:55 +0000180 of the output IRSB.
sewardjc87b5ec2006-10-15 13:46:18 +0000181
182 (2) not try to instrument it or modify it in any way.
183
184 For the record, stuff that may be in the preamble at
185 present is:
186
187 - A self-modifying-code check has been requested for this block.
188 The preamble will contain instructions to checksum the block,
189 compare against the expected value, and exit the dispatcher
190 requesting a discard (hence forcing a retranslation) if they
191 don't match.
192
193 - This block is known to be the entry point of a wrapper of some
sewardj358ebea2006-10-15 13:47:43 +0000194 function F. In this case the preamble contains code to write
sewardjc87b5ec2006-10-15 13:46:18 +0000195 the address of the original F (the fn being wrapped) into a
196 'hidden' guest state register _NRADDR. The wrapper can later
197 read this register using a client request and make a
198 non-redirected call to it using another client-request-like
199 magic macro.
200
201 - For platforms that use the AIX ABI (including ppc64-linux), it
sewardj358ebea2006-10-15 13:47:43 +0000202 is necessary to have a preamble even for replacement functions
203 (not just for wrappers), because it is necessary to switch the
204 R2 register (constant-pool pointer) to a different value when
205 swizzling the program counter.
sewardjc87b5ec2006-10-15 13:46:18 +0000206
207 Hence the preamble pushes both R2 and LR (the return address)
208 on a small 16-entry stack in the guest state and sets R2 to an
209 appropriate value for the wrapper/replacement fn. LR is then
210 set so that the wrapper/replacement fn returns to a magic IR
211 stub which restores R2 and LR and returns.
212
213 It's all hugely ugly and fragile. And it places a stringent
214 requirement on m_debuginfo to find out the correct R2 (toc
215 pointer) value for the wrapper/replacement function. So much
216 so that m_redir will refuse to honour a redirect-to-me request
217 if it cannot find (by asking m_debuginfo) a plausible R2 value
218 for 'me'.
219
220 Because this mechanism maintains a shadow stack of (R2,LR)
221 pairs in the guest state, it will fail if the
222 wrapper/redirection function, or anything it calls, longjumps
223 out past the wrapper, because then the magic return stub will
224 not be run and so the shadow stack will not be popped. So it
225 will quickly fill up. Fortunately none of this applies to
226 {x86,amd64,ppc32}-linux; on those platforms, wrappers can
227 longjump and recurse arbitrarily and everything should work
228 fine.
sewardjf1962d32006-10-19 13:22:16 +0000229
230 Note that copying the preamble verbatim may cause complications
231 for your instrumenter if you shadow IR temporaries. See big
232 comment in MC_(instrument) in memcheck/mc_translate.c for
233 details.
sewardjc87b5ec2006-10-15 13:46:18 +0000234 */
sewardj0b9d74a2006-12-24 02:24:11 +0000235 IRSB*(*instrument)(VgCallbackClosure* closure,
236 IRSB* sb_in,
sewardj7ce62392006-10-15 12:48:18 +0000237 VexGuestLayout* layout,
238 VexGuestExtents* vge,
239 IRType gWordTy,
240 IRType hWordTy),
njn43b9a8a2005-05-10 04:37:01 +0000241
242 // Finish up, print out any results, etc. `exitcode' is program's exit
243 // code. The shadow can be found with VG_(get_exit_status_shadow)().
244 void (*fini)(Int)
245);
246
247/* ------------------------------------------------------------------ */
248/* Details */
249
250/* Default value for avg_translations_sizeB (in bytes), indicating typical
251 code expansion of about 6:1. */
sewardj9644cfd2006-10-17 02:25:50 +0000252#define VG_DEFAULT_TRANS_SIZEB 172
njn43b9a8a2005-05-10 04:37:01 +0000253
254/* Information used in the startup message. `name' also determines the
255 string used for identifying suppressions in a suppression file as
256 belonging to this tool. `version' can be NULL, in which case (not
257 surprisingly) no version info is printed; this mechanism is designed for
258 tools distributed with Valgrind that share a version number with
259 Valgrind. Other tools not distributed as part of Valgrind should
260 probably have their own version number. */
261extern void VG_(details_name) ( Char* name );
262extern void VG_(details_version) ( Char* version );
263extern void VG_(details_description) ( Char* description );
264extern void VG_(details_copyright_author) ( Char* copyright_author );
265
266/* Average size of a translation, in bytes, so that the translation
267 storage machinery can allocate memory appropriately. Not critical,
268 setting is optional. */
269extern void VG_(details_avg_translation_sizeB) ( UInt size );
270
271/* String printed if an `tl_assert' assertion fails or VG_(tool_panic)
272 is called. Should probably be an email address. */
273extern void VG_(details_bug_reports_to) ( Char* bug_reports_to );
274
275/* ------------------------------------------------------------------ */
276/* Needs */
277
njn43b9a8a2005-05-10 04:37:01 +0000278/* Should __libc_freeres() be run? Bugs in it can crash the tool. */
279extern void VG_(needs_libc_freeres) ( void );
280
281/* Want to have errors detected by Valgrind's core reported? Includes:
njn0087c502005-07-01 04:15:36 +0000282 - pthread API errors (many; eg. unlocking a non-locked mutex)
283 [currently disabled]
284 - invalid file descriptors to syscalls like read() and write()
njn43b9a8a2005-05-10 04:37:01 +0000285 - bad signal numbers passed to sigaction()
286 - attempt to install signal handler for SIGKILL or SIGSTOP */
287extern void VG_(needs_core_errors) ( void );
288
289/* Booleans that indicate extra operations are defined; if these are True,
290 the corresponding template functions (given below) must be defined. A
291 lot like being a member of a type class. */
292
293/* Want to report errors from tool? This implies use of suppressions, too. */
294extern void VG_(needs_tool_errors) (
295 // Identify if two errors are equal, or equal enough. `res' indicates how
296 // close is "close enough". `res' should be passed on as necessary, eg. if
297 // the Error's `extra' part contains an ExeContext, `res' should be
298 // passed to VG_(eq_ExeContext)() if the ExeContexts are considered. Other
299 // than that, probably don't worry about it unless you have lots of very
300 // similar errors occurring.
301 Bool (*eq_Error)(VgRes res, Error* e1, Error* e2),
302
303 // Print error context.
304 void (*pp_Error)(Error* err),
305
306 // Should fill in any details that could be postponed until after the
307 // decision whether to ignore the error (ie. details not affecting the
308 // result of VG_(tdict).tool_eq_Error()). This saves time when errors
309 // are ignored.
310 // Yuk.
311 // Return value: must be the size of the `extra' part in bytes -- used by
312 // the core to make a copy.
313 UInt (*update_extra)(Error* err),
314
315 // Return value indicates recognition. If recognised, must set skind using
316 // VG_(set_supp_kind)().
317 Bool (*recognised_suppression)(Char* name, Supp* su),
318
319 // Read any extra info for this suppression kind. Most likely for filling
320 // in the `extra' and `string' parts (with VG_(set_supp_{extra, string})())
321 // of a suppression if necessary. Should return False if a syntax error
322 // occurred, True otherwise.
323 Bool (*read_extra_suppression_info)(Int fd, Char* buf, Int nBuf, Supp* su),
324
325 // This should just check the kinds match and maybe some stuff in the
326 // `string' and `extra' field if appropriate (using VG_(get_supp_*)() to
327 // get the relevant suppression parts).
328 Bool (*error_matches_suppression)(Error* err, Supp* su),
329
330 // This should return the suppression name, for --gen-suppressions, or NULL
331 // if that error type cannot be suppressed. This is the inverse of
332 // VG_(tdict).tool_recognised_suppression().
333 Char* (*get_error_name)(Error* err),
334
335 // This should print any extra info for the error, for --gen-suppressions,
336 // including the newline. This is the inverse of
337 // VG_(tdict).tool_read_extra_suppression_info().
338 void (*print_extra_suppression_info)(Error* err)
339);
340
sewardj5155dec2005-10-12 10:09:23 +0000341/* Is information kept by the tool about specific instructions or
342 translations? (Eg. for cachegrind there are cost-centres for every
343 instruction, stored in a per-translation fashion.) If so, the info
344 may have to be discarded when translations are unloaded (eg. due to
345 .so unloading, or otherwise at the discretion of m_transtab, eg
346 when the table becomes too full) to avoid stale information being
347 reused for new translations. */
sewardj0b9d74a2006-12-24 02:24:11 +0000348extern void VG_(needs_superblock_discards) (
sewardj5155dec2005-10-12 10:09:23 +0000349 // Discard any information that pertains to specific translations
sewardj4ba057c2005-10-18 12:04:18 +0000350 // or instructions within the address range given. There are two
351 // possible approaches.
352 // - If info is being stored at a per-translation level, use orig_addr
353 // to identify which translation is being discarded. Each translation
354 // will be discarded exactly once.
sewardj7ce62392006-10-15 12:48:18 +0000355 // This orig_addr will match the closure->nraddr which was passed to
356 // to instrument() (see extensive comments above) when this
357 // translation was made. Note that orig_addr won't necessarily be
358 // the same as the first address in "extents".
sewardj5155dec2005-10-12 10:09:23 +0000359 // - If info is being stored at a per-instruction level, you can get
360 // the address range(s) being discarded by stepping through "extents".
361 // Note that any single instruction may belong to more than one
362 // translation, and so could be covered by the "extents" of more than
363 // one call to this function.
364 // Doing it the first way (as eg. Cachegrind does) is probably easier.
sewardj0b9d74a2006-12-24 02:24:11 +0000365 void (*discard_superblock_info)(Addr64 orig_addr, VexGuestExtents extents)
njn43b9a8a2005-05-10 04:37:01 +0000366);
367
368/* Tool defines its own command line options? */
369extern void VG_(needs_command_line_options) (
370 // Return True if option was recognised. Presumably sets some state to
njna0078592007-03-27 06:46:03 +0000371 // record the option as well. Nb: tools can assume that the argv will
372 // never disappear. So they can, for example, store a pointer to a string
373 // within an option, rather than having to make a copy.
njn43b9a8a2005-05-10 04:37:01 +0000374 Bool (*process_cmd_line_option)(Char* argv),
375
376 // Print out command line usage for options for normal tool operation.
377 void (*print_usage)(void),
378
379 // Print out command line usage for options for debugging the tool.
380 void (*print_debug_usage)(void)
381);
382
383/* Tool defines its own client requests? */
384extern void VG_(needs_client_requests) (
385 // If using client requests, the number of the first request should be equal
386 // to VG_USERREQ_TOOL_BASE('X', 'Y'), where 'X' and 'Y' form a suitable two
387 // character identification for the string. The second and subsequent
388 // requests should follow.
389 //
390 // This function should use the VG_IS_TOOL_USERREQ macro (in
391 // include/valgrind.h) to first check if it's a request for this tool. Then
392 // should handle it if it's recognised (and return True), or return False if
393 // not recognised. arg_block[0] holds the request number, any further args
394 // from the request are in arg_block[1..]. 'ret' is for the return value...
395 // it should probably be filled, if only with 0.
396 Bool (*handle_client_request)(ThreadId tid, UWord* arg_block, UWord* ret)
397);
398
399/* Tool does stuff before and/or after system calls? */
400// Nb: If either of the pre_ functions malloc() something to return, the
401// corresponding post_ function had better free() it!
402extern void VG_(needs_syscall_wrapper) (
403 void (* pre_syscall)(ThreadId tid, UInt syscallno),
sewardja8d8e232005-06-07 20:04:56 +0000404 void (*post_syscall)(ThreadId tid, UInt syscallno, SysRes res)
njn43b9a8a2005-05-10 04:37:01 +0000405);
406
407/* Are tool-state sanity checks performed? */
408// Can be useful for ensuring a tool's correctness. cheap_sanity_check()
409// is called very frequently; expensive_sanity_check() is called less
410// frequently and can be more involved.
411extern void VG_(needs_sanity_checks) (
412 Bool(*cheap_sanity_check)(void),
413 Bool(*expensive_sanity_check)(void)
414);
415
416/* Do we need to see data symbols? */
417extern void VG_(needs_data_syms) ( void );
418
njn09ca09b2005-10-16 17:48:09 +0000419/* Does the tool replace malloc() and friends with its own versions?
420 This has to be combined with the use of a vgpreload_<tool>.so module
421 or it won't work. See massif/Makefile.am for how to build it. */
njn43b9a8a2005-05-10 04:37:01 +0000422// The 'p' prefix avoids GCC complaints about overshadowing global names.
njnfc51f8d2005-06-21 03:20:17 +0000423extern void VG_(needs_malloc_replacement)(
njn43b9a8a2005-05-10 04:37:01 +0000424 void* (*pmalloc) ( ThreadId tid, SizeT n ),
425 void* (*p__builtin_new) ( ThreadId tid, SizeT n ),
426 void* (*p__builtin_vec_new) ( ThreadId tid, SizeT n ),
427 void* (*pmemalign) ( ThreadId tid, SizeT align, SizeT n ),
428 void* (*pcalloc) ( ThreadId tid, SizeT nmemb, SizeT size1 ),
429 void (*pfree) ( ThreadId tid, void* p ),
430 void (*p__builtin_delete) ( ThreadId tid, void* p ),
431 void (*p__builtin_vec_delete) ( ThreadId tid, void* p ),
432 void* (*prealloc) ( ThreadId tid, void* p, SizeT new_size ),
433 SizeT client_malloc_redzone_szB
434);
435
njnca54af32006-04-16 10:25:43 +0000436/* Can the tool do XML output? This is a slight misnomer, because the tool
437 * is not requesting the core to do anything, rather saying "I can handle
438 * it". */
439extern void VG_(needs_xml_output)( void );
440
sewardj81651dc2007-08-28 06:05:20 +0000441/* Does the tool want to have one final pass over the IR after tree
442 building but before instruction selection? If so specify the
443 function here. */
444extern void VG_(needs_final_IR_tidy_pass) ( IRSB*(*final_tidy)(IRSB*) );
445
446
njn43b9a8a2005-05-10 04:37:01 +0000447/* ------------------------------------------------------------------ */
448/* Core events to track */
449
450/* Part of the core from which this call was made. Useful for determining
451 what kind of error message should be emitted. */
452typedef
njnbb6311c2006-12-15 04:37:25 +0000453 enum { Vg_CoreStartup, Vg_CoreSignal, Vg_CoreSysCall,
njn43b9a8a2005-05-10 04:37:01 +0000454 Vg_CoreTranslate, Vg_CoreClientReq }
455 CorePart;
456
457/* Events happening in core to track. To be notified, pass a callback
458 function to the appropriate function. To ignore an event, don't do
459 anything (the default is for events to be ignored).
460
461 Note that most events aren't passed a ThreadId. If the event is one called
462 from generated code (eg. new_mem_stack_*), you can use
463 VG_(get_running_tid)() to find it. Otherwise, it has to be passed in,
464 as in pre_mem_read, and so the event signature will require changing.
465
466 Memory events (Nb: to track heap allocation/freeing, a tool must replace
467 malloc() et al. See above how to do this.)
468
469 These ones occur at startup, upon some signals, and upon some syscalls
470 */
471void VG_(track_new_mem_startup) (void(*f)(Addr a, SizeT len,
472 Bool rr, Bool ww, Bool xx));
473void VG_(track_new_mem_stack_signal)(void(*f)(Addr a, SizeT len));
474void VG_(track_new_mem_brk) (void(*f)(Addr a, SizeT len));
475void VG_(track_new_mem_mmap) (void(*f)(Addr a, SizeT len,
476 Bool rr, Bool ww, Bool xx));
477
478void VG_(track_copy_mem_remap) (void(*f)(Addr from, Addr to, SizeT len));
479void VG_(track_change_mem_mprotect) (void(*f)(Addr a, SizeT len,
480 Bool rr, Bool ww, Bool xx));
481void VG_(track_die_mem_stack_signal)(void(*f)(Addr a, SizeT len));
482void VG_(track_die_mem_brk) (void(*f)(Addr a, SizeT len));
483void VG_(track_die_mem_munmap) (void(*f)(Addr a, SizeT len));
484
485/* These ones are called when SP changes. A tool could track these itself
486 (except for ban_mem_stack) but it's much easier to use the core's help.
487
488 The specialised ones are called in preference to the general one, if they
489 are defined. These functions are called a lot if they are used, so
490 specialising can optimise things significantly. If any of the
491 specialised cases are defined, the general case must be defined too.
492
njnaf839f52005-06-23 03:27:57 +0000493 Nb: all the specialised ones must use the VG_REGPARM(n) attribute.
njn43b9a8a2005-05-10 04:37:01 +0000494 */
sewardjf5c8e372006-02-12 15:42:20 +0000495void VG_(track_new_mem_stack_4) (VG_REGPARM(1) void(*f)(Addr new_ESP));
496void VG_(track_new_mem_stack_8) (VG_REGPARM(1) void(*f)(Addr new_ESP));
497void VG_(track_new_mem_stack_12) (VG_REGPARM(1) void(*f)(Addr new_ESP));
498void VG_(track_new_mem_stack_16) (VG_REGPARM(1) void(*f)(Addr new_ESP));
499void VG_(track_new_mem_stack_32) (VG_REGPARM(1) void(*f)(Addr new_ESP));
500void VG_(track_new_mem_stack_112)(VG_REGPARM(1) void(*f)(Addr new_ESP));
501void VG_(track_new_mem_stack_128)(VG_REGPARM(1) void(*f)(Addr new_ESP));
502void VG_(track_new_mem_stack_144)(VG_REGPARM(1) void(*f)(Addr new_ESP));
503void VG_(track_new_mem_stack_160)(VG_REGPARM(1) void(*f)(Addr new_ESP));
504void VG_(track_new_mem_stack) (void(*f)(Addr a, SizeT len));
njn43b9a8a2005-05-10 04:37:01 +0000505
sewardjf5c8e372006-02-12 15:42:20 +0000506void VG_(track_die_mem_stack_4) (VG_REGPARM(1) void(*f)(Addr die_ESP));
507void VG_(track_die_mem_stack_8) (VG_REGPARM(1) void(*f)(Addr die_ESP));
508void VG_(track_die_mem_stack_12) (VG_REGPARM(1) void(*f)(Addr die_ESP));
509void VG_(track_die_mem_stack_16) (VG_REGPARM(1) void(*f)(Addr die_ESP));
510void VG_(track_die_mem_stack_32) (VG_REGPARM(1) void(*f)(Addr die_ESP));
511void VG_(track_die_mem_stack_112)(VG_REGPARM(1) void(*f)(Addr die_ESP));
512void VG_(track_die_mem_stack_128)(VG_REGPARM(1) void(*f)(Addr die_ESP));
513void VG_(track_die_mem_stack_144)(VG_REGPARM(1) void(*f)(Addr die_ESP));
514void VG_(track_die_mem_stack_160)(VG_REGPARM(1) void(*f)(Addr die_ESP));
515void VG_(track_die_mem_stack) (void(*f)(Addr a, SizeT len));
njn43b9a8a2005-05-10 04:37:01 +0000516
517/* Used for redzone at end of thread stacks */
518void VG_(track_ban_mem_stack) (void(*f)(Addr a, SizeT len));
519
520/* These ones occur around syscalls, signal handling, etc */
521void VG_(track_pre_mem_read) (void(*f)(CorePart part, ThreadId tid,
522 Char* s, Addr a, SizeT size));
523void VG_(track_pre_mem_read_asciiz)(void(*f)(CorePart part, ThreadId tid,
524 Char* s, Addr a));
525void VG_(track_pre_mem_write) (void(*f)(CorePart part, ThreadId tid,
526 Char* s, Addr a, SizeT size));
527void VG_(track_post_mem_write) (void(*f)(CorePart part, ThreadId tid,
528 Addr a, SizeT size));
529
530/* Register events. Use VG_(set_shadow_state_area)() to set the shadow regs
531 for these events. */
532void VG_(track_pre_reg_read) (void(*f)(CorePart part, ThreadId tid,
533 Char* s, OffT guest_state_offset,
534 SizeT size));
535void VG_(track_post_reg_write)(void(*f)(CorePart part, ThreadId tid,
536 OffT guest_state_offset,
537 SizeT size));
538
539/* This one is called for malloc() et al if they are replaced by a tool. */
540void VG_(track_post_reg_write_clientcall_return)(
541 void(*f)(ThreadId tid, OffT guest_state_offset, SizeT size, Addr f));
542
543
544/* Scheduler events (not exhaustive) */
sewardj97561812006-12-23 01:21:12 +0000545
546/* Called when 'tid' starts or stops running client code blocks.
njn3e32c872006-12-24 07:51:17 +0000547 Gives the total dispatched block count at that event. Note, this is
548 not the same as 'tid' holding the BigLock (the lock that ensures that
549 only one thread runs at a time): a thread can hold the lock for other
550 purposes (making translations, etc) yet not be running client blocks.
551 Obviously though, a thread must hold the lock in order to run client
552 code blocks, so the times bracketed by 'thread_run'..'thread_runstate'
553 are a subset of the times when thread 'tid' holds the cpu lock.
sewardj97561812006-12-23 01:21:12 +0000554*/
njn3e32c872006-12-24 07:51:17 +0000555void VG_(track_start_client_code)(
556 void(*f)(ThreadId tid, ULong blocks_dispatched)
557 );
558void VG_(track_stop_client_code)(
559 void(*f)(ThreadId tid, ULong blocks_dispatched)
sewardj97561812006-12-23 01:21:12 +0000560 );
njn43b9a8a2005-05-10 04:37:01 +0000561
562
563/* Thread events (not exhaustive)
564
565 Called during thread create, before the new thread has run any
566 instructions (or touched any memory).
567 */
568void VG_(track_post_thread_create)(void(*f)(ThreadId tid, ThreadId child));
569void VG_(track_post_thread_join) (void(*f)(ThreadId joiner, ThreadId joinee));
570
njn3e32c872006-12-24 07:51:17 +0000571
njn43b9a8a2005-05-10 04:37:01 +0000572/* Signal events (not exhaustive)
573
574 ... pre_send_signal, post_send_signal ...
575
576 Called before a signal is delivered; `alt_stack' indicates if it is
577 delivered on an alternative stack. */
578void VG_(track_pre_deliver_signal) (void(*f)(ThreadId tid, Int sigNo,
579 Bool alt_stack));
580/* Called after a signal is delivered. Nb: unfortunately, if the signal
581 handler longjmps, this won't be called. */
582void VG_(track_post_deliver_signal)(void(*f)(ThreadId tid, Int sigNo));
583
njn43b9a8a2005-05-10 04:37:01 +0000584#endif // __PUB_TOOL_TOOLIFACE_H
585
586/*--------------------------------------------------------------------*/
587/*--- end ---*/
588/*--------------------------------------------------------------------*/