blob: 3a82231a7b44282f8ee1dbacd98aed39ec11b282 [file] [log] [blame]
sewardjac9af022004-07-05 01:15:34 +00001
2/*---------------------------------------------------------------*/
3/*--- ---*/
sewardj887a11a2004-07-05 17:26:47 +00004/*--- This file (libvex.h) is ---*/
sewardjdbcfae72005-08-02 11:14:04 +00005/*--- Copyright (C) OpenWorks LLP. All rights reserved. ---*/
sewardjac9af022004-07-05 01:15:34 +00006/*--- ---*/
7/*---------------------------------------------------------------*/
8
sewardjf8ed9d82004-11-12 17:40:23 +00009/*
10 This file is part of LibVEX, a library for dynamic binary
11 instrumentation and translation.
12
sewardja26d8202008-02-11 11:35:40 +000013 Copyright (C) 2004-2008 OpenWorks LLP. All rights reserved.
sewardjf8ed9d82004-11-12 17:40:23 +000014
sewardj7bd6ffe2005-08-03 16:07:36 +000015 This library is made available under a dual licensing scheme.
sewardjf8ed9d82004-11-12 17:40:23 +000016
sewardj7bd6ffe2005-08-03 16:07:36 +000017 If you link LibVEX against other code all of which is itself
18 licensed under the GNU General Public License, version 2 dated June
19 1991 ("GPL v2"), then you may use LibVEX under the terms of the GPL
20 v2, as appearing in the file LICENSE.GPL. If the file LICENSE.GPL
21 is missing, you can obtain a copy of the GPL v2 from the Free
22 Software Foundation Inc., 51 Franklin St, Fifth Floor, Boston, MA
23 02110-1301, USA.
24
25 For any other uses of LibVEX, you must first obtain a commercial
26 license from OpenWorks LLP. Please contact info@open-works.co.uk
27 for information about commercial licensing.
28
29 This software is provided by OpenWorks LLP "as is" and any express
30 or implied warranties, including, but not limited to, the implied
31 warranties of merchantability and fitness for a particular purpose
32 are disclaimed. In no event shall OpenWorks LLP be liable for any
33 direct, indirect, incidental, special, exemplary, or consequential
34 damages (including, but not limited to, procurement of substitute
35 goods or services; loss of use, data, or profits; or business
36 interruption) however caused and on any theory of liability,
37 whether in contract, strict liability, or tort (including
38 negligence or otherwise) arising in any way out of the use of this
39 software, even if advised of the possibility of such damage.
sewardjf8ed9d82004-11-12 17:40:23 +000040
41 Neither the names of the U.S. Department of Energy nor the
42 University of California nor the names of its contributors may be
43 used to endorse or promote products derived from this software
44 without prior written permission.
sewardjf8ed9d82004-11-12 17:40:23 +000045*/
46
sewardj887a11a2004-07-05 17:26:47 +000047#ifndef __LIBVEX_H
48#define __LIBVEX_H
sewardjac9af022004-07-05 01:15:34 +000049
50
sewardj887a11a2004-07-05 17:26:47 +000051#include "libvex_basictypes.h"
52#include "libvex_ir.h"
sewardjac9af022004-07-05 01:15:34 +000053
54
55/*---------------------------------------------------------------*/
sewardjd887b862005-01-17 18:34:34 +000056/*--- This file defines the top-level interface to LibVEX. ---*/
sewardjac9af022004-07-05 01:15:34 +000057/*---------------------------------------------------------------*/
58
sewardjd887b862005-01-17 18:34:34 +000059/*-------------------------------------------------------*/
sewardj27e1dd62005-06-30 11:49:14 +000060/*--- Architectures, variants, and other arch info ---*/
sewardjd887b862005-01-17 18:34:34 +000061/*-------------------------------------------------------*/
sewardjbef170b2004-12-21 01:23:00 +000062
63typedef
64 enum {
65 VexArch_INVALID,
66 VexArchX86,
67 VexArchAMD64,
cerion896a1372005-01-25 12:24:25 +000068 VexArchARM,
ceriond953ebb2005-11-29 13:27:20 +000069 VexArchPPC32,
70 VexArchPPC64
sewardjbef170b2004-12-21 01:23:00 +000071 }
72 VexArch;
73
sewardj5117ce12006-01-27 21:20:15 +000074
75/* For a given architecture, these specify extra capabilities beyond
76 the minimum supported (baseline) capabilities. They may be OR'd
77 together, although some combinations don't make sense. (eg, SSE2
78 but not SSE1). LibVEX_Translate will check for nonsensical
79 combinations. */
80
sewardje9d8a262009-07-01 08:06:34 +000081/* x86: baseline capability is Pentium-1 (FPU, MMX, but no SSE), with
82 cmpxchg8b. */
sewardj5117ce12006-01-27 21:20:15 +000083#define VEX_HWCAPS_X86_SSE1 (1<<1) /* SSE1 support (Pentium III) */
84#define VEX_HWCAPS_X86_SSE2 (1<<2) /* SSE2 support (Pentium 4) */
85#define VEX_HWCAPS_X86_SSE3 (1<<3) /* SSE3 support (>= Prescott) */
86
sewardje9d8a262009-07-01 08:06:34 +000087/* amd64: baseline capability is SSE2, with cmpxchg8b but not
88 cmpxchg16b. */
sewardj5117ce12006-01-27 21:20:15 +000089#define VEX_HWCAPS_AMD64_SSE3 (1<<4) /* SSE3 support */
sewardje9d8a262009-07-01 08:06:34 +000090#define VEX_HWCAPS_AMD64_CX16 (1<<5) /* cmpxchg16b support */
sewardj5117ce12006-01-27 21:20:15 +000091
92/* ppc32: baseline capability is integer only */
sewardje9d8a262009-07-01 08:06:34 +000093#define VEX_HWCAPS_PPC32_F (1<<6) /* basic (non-optional) FP */
94#define VEX_HWCAPS_PPC32_V (1<<7) /* Altivec (VMX) */
95#define VEX_HWCAPS_PPC32_FX (1<<8) /* FP extns (fsqrt, fsqrts) */
96#define VEX_HWCAPS_PPC32_GX (1<<9) /* Graphics extns
sewardj5117ce12006-01-27 21:20:15 +000097 (fres,frsqrte,fsel,stfiwx) */
98
99/* ppc64: baseline capability is integer and basic FP insns */
sewardje9d8a262009-07-01 08:06:34 +0000100#define VEX_HWCAPS_PPC64_V (1<<10) /* Altivec (VMX) */
101#define VEX_HWCAPS_PPC64_FX (1<<11) /* FP extns (fsqrt, fsqrts) */
102#define VEX_HWCAPS_PPC64_GX (1<<12) /* Graphics extns
sewardj5117ce12006-01-27 21:20:15 +0000103 (fres,frsqrte,fsel,stfiwx) */
104
105/* arm: baseline capability is ARMv4 */
106/* No extra capabilities */
107
sewardjbef170b2004-12-21 01:23:00 +0000108
109/* These return statically allocated strings. */
110
111extern const HChar* LibVEX_ppVexArch ( VexArch );
sewardj5117ce12006-01-27 21:20:15 +0000112extern const HChar* LibVEX_ppVexHwCaps ( VexArch, UInt );
sewardjbef170b2004-12-21 01:23:00 +0000113
sewardjac9af022004-07-05 01:15:34 +0000114
sewardj27e1dd62005-06-30 11:49:14 +0000115/* This struct is a bit of a hack, but is needed to carry misc
sewardjaca070a2006-10-17 00:28:22 +0000116 important bits of info about an arch. Fields which are meaningless
117 or ignored for the platform in question should be set to zero. */
sewardj27e1dd62005-06-30 11:49:14 +0000118
119typedef
120 struct {
121 /* This is the only mandatory field. */
sewardj5117ce12006-01-27 21:20:15 +0000122 UInt hwcaps;
ceriond953ebb2005-11-29 13:27:20 +0000123 /* PPC32/PPC64 only: size of cache line */
cerion5b2325f2005-12-23 00:55:09 +0000124 Int ppc_cache_line_szB;
sewardj27e1dd62005-06-30 11:49:14 +0000125 }
126 VexArchInfo;
127
128/* Write default settings info *vai. */
129extern
130void LibVEX_default_VexArchInfo ( /*OUT*/VexArchInfo* vai );
131
132
sewardjaca070a2006-10-17 00:28:22 +0000133/* This struct carries guest and host ABI variant information that may
134 be needed. Fields which are meaningless or ignored for the
135 platform in question should be set to zero.
136
137 Settings which are believed to be correct are:
138
139 guest_stack_redzone_size
140 guest is ppc32-linux ==> 0
141 guest is ppc64-linux ==> 288
142 guest is ppc32-aix5 ==> 220
143 guest is ppc64-aix5 ==> unknown
144 guest is amd64-linux ==> 128
145 guest is other ==> inapplicable
146
sewardj2e28ac42008-12-04 00:05:12 +0000147 guest_amd64_assume_fs_is_zero
148 guest is amd64-linux ==> True
149 guest is amd64-darwin ==> False
150 guest is other ==> inapplicable
151
152 guest_amd64_assume_gs_is_0x60
153 guest is amd64-darwin ==> True
154 guest is amd64-linux ==> False
155 guest is other ==> inapplicable
156
sewardjaca070a2006-10-17 00:28:22 +0000157 guest_ppc_zap_RZ_at_blr
158 guest is ppc64-linux ==> True
159 guest is ppc32-linux ==> False
160 guest is ppc64-aix5 ==> unknown
161 guest is ppc32-aix5 ==> False
162 guest is other ==> inapplicable
163
164 guest_ppc_zap_RZ_at_bl
165 guest is ppc64-linux ==> const True
166 guest is ppc32-linux ==> const False
167 guest is ppc64-aix5 ==> unknown
168 guest is ppc32-aix5 ==> True except for calls to
169 millicode, $SAVEFn, $RESTFn
170 guest is other ==> inapplicable
171
172 guest_ppc_sc_continues_at_LR:
173 guest is ppc32-aix5 or ppc64-aix5 ==> True
174 guest is ppc32-linux or ppc64-linux ==> False
175 guest is other ==> inapplicable
176
177 host_ppc_calls_use_fndescrs:
178 host is ppc32-linux ==> False
179 host is ppc64-linux ==> True
180 host is ppc32-aix5 or ppc64-aix5 ==> True
181 host is other ==> inapplicable
182
183 host_ppc32_regalign_int64_args:
184 host is ppc32-linux ==> True
185 host is ppc32-aix5 ==> False
186 host is other ==> inapplicable
187*/
188
189typedef
190 struct {
191 /* PPC and AMD64 GUESTS only: how many bytes below the
192 stack pointer are validly addressible? */
193 Int guest_stack_redzone_size;
194
sewardj2e28ac42008-12-04 00:05:12 +0000195 /* AMD64 GUESTS only: should we translate %fs-prefixed
196 instructions using the assumption that %fs always contains
197 zero? */
198 Bool guest_amd64_assume_fs_is_zero;
199
200 /* AMD64 GUESTS only: should we translate %gs-prefixed
201 instructions using the assumption that %gs always contains
202 0x60? */
203 Bool guest_amd64_assume_gs_is_0x60;
204
sewardjaca070a2006-10-17 00:28:22 +0000205 /* PPC GUESTS only: should we zap the stack red zone at a 'blr'
206 (function return) ? */
207 Bool guest_ppc_zap_RZ_at_blr;
208
209 /* PPC GUESTS only: should we zap the stack red zone at a 'bl'
210 (function call) ? Is supplied with the guest address of the
211 target of the call since that may be significant. If NULL,
212 is assumed equivalent to a fn which always returns False. */
213 Bool (*guest_ppc_zap_RZ_at_bl)(Addr64);
214
215 /* PPC32/PPC64 GUESTS only: where does the kernel resume after
216 'sc'? False => Linux style, at the next insn. True => AIX
217 style, at the address stated in the link register. */
218 Bool guest_ppc_sc_continues_at_LR;
219
220 /* PPC32/PPC64 HOSTS only: does '&f' give us a pointer to a
221 function descriptor on the host, or to the function code
222 itself? True => descriptor, False => code. */
223 Bool host_ppc_calls_use_fndescrs;
224
225 /* PPC32 HOSTS only: when generating code to pass a 64-bit value
226 (actual parameter) in a pair of regs, should we skip an arg
227 reg if it is even-numbered? True => yes, False => no. */
228 Bool host_ppc32_regalign_int64_args;
229 }
sewardjdd40fdf2006-12-24 02:20:24 +0000230 VexAbiInfo;
sewardjaca070a2006-10-17 00:28:22 +0000231
sewardjdd40fdf2006-12-24 02:20:24 +0000232/* Write default settings info *vbi. */
sewardjaca070a2006-10-17 00:28:22 +0000233extern
sewardjdd40fdf2006-12-24 02:20:24 +0000234void LibVEX_default_VexAbiInfo ( /*OUT*/VexAbiInfo* vbi );
sewardjaca070a2006-10-17 00:28:22 +0000235
236
sewardjd887b862005-01-17 18:34:34 +0000237/*-------------------------------------------------------*/
238/*--- Control of Vex's optimiser (iropt). ---*/
239/*-------------------------------------------------------*/
240
sewardj08613742004-10-25 13:01:45 +0000241/* Control of Vex's optimiser. */
242
243typedef
244 struct {
245 /* Controls verbosity of iropt. 0 = no output. */
246 Int iropt_verbosity;
247 /* Control aggressiveness of iropt. 0 = no opt, 1 = simple
248 opts, 2 (default) = max optimisation. */
249 Int iropt_level;
250 /* Ensure all integer registers are up to date at potential
251 memory exception points? True(default)=yes, False=no, only
252 the guest's stack pointer. */
253 Bool iropt_precise_memory_exns;
254 /* How aggressive should iropt be in unrolling loops? Higher
255 numbers make it more enthusiastic about loop unrolling.
256 Default=120. A setting of zero disables unrolling. */
257 Int iropt_unroll_thresh;
258 /* What's the maximum basic block length the front end(s) allow?
259 BBs longer than this are split up. Default=50 (guest
260 insns). */
261 Int guest_max_insns;
262 /* How aggressive should front ends be in following
263 unconditional branches to known destinations? Default=10,
264 meaning that if a block contains less than 10 guest insns so
265 far, the front end(s) will attempt to chase into its
266 successor. A setting of zero disables chasing. */
267 Int guest_chase_thresh;
268 }
269 VexControl;
270
271
272/* Write the default settings into *vcon. */
sewardjbef170b2004-12-21 01:23:00 +0000273
sewardjd887b862005-01-17 18:34:34 +0000274extern
275void LibVEX_default_VexControl ( /*OUT*/ VexControl* vcon );
sewardj08613742004-10-25 13:01:45 +0000276
277
sewardjd887b862005-01-17 18:34:34 +0000278/*-------------------------------------------------------*/
279/*--- Version information ---*/
280/*-------------------------------------------------------*/
sewardj80f5fce2004-12-20 04:37:50 +0000281
sewardjd887b862005-01-17 18:34:34 +0000282/* Returns the Vex SVN version, as a statically allocated string. */
283
284extern const HChar* LibVEX_Version ( void );
sewardj80f5fce2004-12-20 04:37:50 +0000285
286
sewardjd887b862005-01-17 18:34:34 +0000287/*-------------------------------------------------------*/
288/*--- Storage management control ---*/
289/*-------------------------------------------------------*/
sewardjac9af022004-07-05 01:15:34 +0000290
sewardjd887b862005-01-17 18:34:34 +0000291/* Allocate in Vex's temporary allocation area. Be careful with this.
292 You can only call it inside an instrumentation or optimisation
293 callback that you have previously specified in a call to
294 LibVEX_Translate. The storage allocated will only stay alive until
295 translation of the current basic block is complete.
296 */
sewardj2d6b14a2005-11-23 04:25:07 +0000297extern HChar* private_LibVEX_alloc_first;
298extern HChar* private_LibVEX_alloc_curr;
299extern HChar* private_LibVEX_alloc_last;
300extern void private_LibVEX_alloc_OOM(void) __attribute__((noreturn));
301
302static inline void* LibVEX_Alloc ( Int nbytes )
303{
304#if 0
305 /* Nasty debugging hack, do not use. */
306 return malloc(nbytes);
307#else
308 HChar* curr;
309 HChar* next;
310 Int ALIGN;
311 ALIGN = sizeof(void*)-1;
312 nbytes = (nbytes + ALIGN) & ~ALIGN;
313 curr = private_LibVEX_alloc_curr;
314 next = curr + nbytes;
315 if (next >= private_LibVEX_alloc_last)
316 private_LibVEX_alloc_OOM();
317 private_LibVEX_alloc_curr = next;
318 return curr;
319#endif
320}
sewardjac9af022004-07-05 01:15:34 +0000321
sewardjd887b862005-01-17 18:34:34 +0000322/* Show Vex allocation statistics. */
323extern void LibVEX_ShowAllocStats ( void );
324
325
326/*-------------------------------------------------------*/
327/*--- Describing guest state layout ---*/
328/*-------------------------------------------------------*/
sewardjac9af022004-07-05 01:15:34 +0000329
sewardj49651f42004-10-28 22:11:04 +0000330/* Describe the guest state enough that the instrumentation
331 functions can work. */
332
sewardjeeac8412004-11-02 00:26:55 +0000333/* The max number of guest state chunks which we can describe as
334 always defined (for the benefit of Memcheck). */
sewardje86310f2009-03-19 22:21:40 +0000335#define VEXGLO_N_ALWAYSDEFD 24
sewardjeeac8412004-11-02 00:26:55 +0000336
sewardj49651f42004-10-28 22:11:04 +0000337typedef
338 struct {
sewardjcf787902004-11-03 09:08:33 +0000339 /* Total size of the guest state, in bytes. Must be
340 8-aligned. */
sewardjeeac8412004-11-02 00:26:55 +0000341 Int total_sizeB;
sewardj49651f42004-10-28 22:11:04 +0000342 /* Whereabouts is the stack pointer? */
343 Int offset_SP;
344 Int sizeof_SP; /* 4 or 8 */
sewardja2033302008-08-19 11:15:10 +0000345 /* Whereabouts is the frame pointer? */
346 Int offset_FP;
347 Int sizeof_FP; /* 4 or 8 */
sewardjcf787902004-11-03 09:08:33 +0000348 /* Whereabouts is the instruction pointer? */
349 Int offset_IP;
350 Int sizeof_IP; /* 4 or 8 */
sewardjeeac8412004-11-02 00:26:55 +0000351 /* Describe parts of the guest state regarded as 'always
352 defined'. */
353 Int n_alwaysDefd;
354 struct {
355 Int offset;
356 Int size;
357 } alwaysDefd[VEXGLO_N_ALWAYSDEFD];
sewardj49651f42004-10-28 22:11:04 +0000358 }
sewardjeeac8412004-11-02 00:26:55 +0000359 VexGuestLayout;
sewardj49651f42004-10-28 22:11:04 +0000360
sewardjd887b862005-01-17 18:34:34 +0000361/* A note about guest state layout.
sewardj49651f42004-10-28 22:11:04 +0000362
sewardjd887b862005-01-17 18:34:34 +0000363 LibVEX defines the layout for the guest state, in the file
sewardj478646f2008-05-01 20:13:04 +0000364 pub/libvex_guest_<arch>.h. The struct will have an 16-aligned
365 size. Each translated bb is assumed to be entered with a specified
366 register pointing at such a struct. Beyond that is two copies of
367 the shadow state area with the same size as the struct. Beyond
368 that is a spill area that LibVEX may spill into. It must have size
sewardjd887b862005-01-17 18:34:34 +0000369 LibVEX_N_SPILL_BYTES, and this must be a 16-aligned number.
370
sewardj478646f2008-05-01 20:13:04 +0000371 On entry, the baseblock pointer register must be 16-aligned.
372
373 There must be no holes in between the primary guest state, its two
374 copies, and the spill area. In short, all 4 areas must have a
375 16-aligned size and be 16-aligned, and placed back-to-back.
sewardjd887b862005-01-17 18:34:34 +0000376*/
377
sewardj21bd7c72006-03-16 11:29:13 +0000378#define LibVEX_N_SPILL_BYTES 2048
sewardjd887b862005-01-17 18:34:34 +0000379
380
381/*-------------------------------------------------------*/
382/*--- Initialisation of the library ---*/
383/*-------------------------------------------------------*/
384
385/* Initialise the library. You must call this first. */
386
387extern void LibVEX_Init (
388 /* failure exit function */
389 __attribute__ ((noreturn))
390 void (*failure_exit) ( void ),
391 /* logging output function */
sewardj58277842005-02-07 03:11:17 +0000392 void (*log_bytes) ( HChar*, Int nbytes ),
sewardjd887b862005-01-17 18:34:34 +0000393 /* debug paranoia level */
394 Int debuglevel,
395 /* Are we supporting valgrind checking? */
396 Bool valgrind_support,
397 /* Control ... */
398 /*READONLY*/VexControl* vcon
399);
400
401
402/*-------------------------------------------------------*/
403/*--- Make a translation ---*/
404/*-------------------------------------------------------*/
sewardjac9af022004-07-05 01:15:34 +0000405
sewardj72c72812005-01-19 11:49:45 +0000406/* Describes the outcome of a translation attempt. */
sewardjac9af022004-07-05 01:15:34 +0000407typedef
sewardjd887b862005-01-17 18:34:34 +0000408 enum {
409 VexTransOK,
410 VexTransAccessFail,
411 VexTransOutputFull
412 }
413 VexTranslateResult;
sewardjac9af022004-07-05 01:15:34 +0000414
sewardj72c72812005-01-19 11:49:45 +0000415
416/* Describes precisely the pieces of guest code that a translation
417 covers. Now that Vex can chase across BB boundaries, the old
418 scheme of describing a chunk of guest code merely by its start
419 address and length is inadequate.
420
421 Hopefully this struct is only 32 bytes long. Space is important as
422 clients will have to store one of these for each translation made.
423*/
424typedef
425 struct {
426 Addr64 base[3];
427 UShort len[3];
428 UShort n_used;
429 }
430 VexGuestExtents;
431
432
sewardj17c7f952005-12-15 14:02:34 +0000433/* A structure to carry arguments for LibVEX_Translate. There are so
434 many of them, it seems better to have a structure. */
435typedef
436 struct {
sewardjaca070a2006-10-17 00:28:22 +0000437 /* IN: The instruction sets we are translating from and to. And
438 guest/host misc info. */
sewardj17c7f952005-12-15 14:02:34 +0000439 VexArch arch_guest;
440 VexArchInfo archinfo_guest;
441 VexArch arch_host;
442 VexArchInfo archinfo_host;
sewardjdd40fdf2006-12-24 02:20:24 +0000443 VexAbiInfo abiinfo_both;
sewardjf4611492005-10-18 12:01:48 +0000444
sewardjc716aea2006-01-17 01:48:46 +0000445 /* IN: an opaque value which is passed as the first arg to all
446 callback functions supplied in this struct. Vex has no idea
447 what's at the other end of this pointer. */
448 void* callback_opaque;
449
sewardj17c7f952005-12-15 14:02:34 +0000450 /* IN: the block to translate, and its guest address. */
451 /* where are the actual bytes in the host's address space? */
452 UChar* guest_bytes;
453 /* where do the bytes really come from in the guest's aspace?
sewardjc716aea2006-01-17 01:48:46 +0000454 This is the post-redirection guest address. Not that Vex
455 understands anything about redirection; that is all done on
456 the Valgrind side. */
sewardj17c7f952005-12-15 14:02:34 +0000457 Addr64 guest_bytes_addr;
sewardj17c7f952005-12-15 14:02:34 +0000458
459 /* Is it OK to chase into this guest address? May not be
460 NULL. */
sewardjc716aea2006-01-17 01:48:46 +0000461 Bool (*chase_into_ok) ( /*callback_opaque*/void*, Addr64 );
sewardj17c7f952005-12-15 14:02:34 +0000462
463 /* OUT: which bits of guest code actually got translated */
464 VexGuestExtents* guest_extents;
465
466 /* IN: a place to put the resulting code, and its size */
467 UChar* host_bytes;
468 Int host_bytes_size;
469 /* OUT: how much of the output area is used. */
470 Int* host_bytes_used;
471
472 /* IN: optionally, two instrumentation functions. May be
473 NULL. */
sewardjdd40fdf2006-12-24 02:20:24 +0000474 IRSB* (*instrument1) ( /*callback_opaque*/void*,
475 IRSB*,
sewardjc716aea2006-01-17 01:48:46 +0000476 VexGuestLayout*,
477 VexGuestExtents*,
sewardj17c7f952005-12-15 14:02:34 +0000478 IRType gWordTy, IRType hWordTy );
sewardjdd40fdf2006-12-24 02:20:24 +0000479 IRSB* (*instrument2) ( /*callback_opaque*/void*,
480 IRSB*,
sewardjc716aea2006-01-17 01:48:46 +0000481 VexGuestLayout*,
482 VexGuestExtents*,
sewardj17c7f952005-12-15 14:02:34 +0000483 IRType gWordTy, IRType hWordTy );
484
sewardjbe1b6ff2007-08-28 06:06:27 +0000485 IRSB* (*finaltidy) ( IRSB* );
486
sewardj17c7f952005-12-15 14:02:34 +0000487 /* IN: should this translation be self-checking? default: False */
488 Bool do_self_check;
sewardjc716aea2006-01-17 01:48:46 +0000489
490 /* IN: optionally, a callback which allows the caller to add its
491 own IR preamble following the self-check and any other
492 VEX-generated preamble, if any. May be NULL. If non-NULL,
sewardjf6c8ebf2007-02-06 01:52:52 +0000493 the IRSB under construction is handed to this function, which
sewardjc716aea2006-01-17 01:48:46 +0000494 presumably adds IR statements to it. The callback may
495 optionally complete the block and direct bb_to_IR not to
496 disassemble any instructions into it; this is indicated by
497 the callback returning True.
498 */
sewardjdd40fdf2006-12-24 02:20:24 +0000499 Bool (*preamble_function)(/*callback_opaque*/void*, IRSB*);
sewardjce02aa72006-01-12 12:27:58 +0000500
sewardj17c7f952005-12-15 14:02:34 +0000501 /* IN: debug: trace vex activity at various points */
502 Int traceflags;
503
504 /* IN: address of the dispatcher entry point. Describes the
505 place where generated code should jump to at the end of each
506 bb.
507
508 At the end of each translation, the next guest address is
509 placed in the host's standard return register (x86: %eax,
510 amd64: %rax, ppc32: %r3, ppc64: %r3). Optionally, the guest
511 state pointer register (on host x86: %ebp; amd64: %rbp;
512 ppc32/64: r31) may be set to a VEX_TRC_ value to indicate any
513 special action required before the next block is run.
514
515 Control is then passed back to the dispatcher (beyond Vex's
516 control; caller supplies this) in the following way:
517
518 - On host archs which lack a link register (x86, amd64), by a
519 jump to the host address specified in 'dispatcher', which
520 must be non-NULL.
521
522 - On host archs which have a link register (ppc32, ppc64), by
523 a branch to the link register (which is guaranteed to be
524 unchanged from whatever it was at entry to the
525 translation). 'dispatch' must be NULL.
526
527 The aim is to get back and forth between translations and the
528 dispatcher without creating memory traffic to store return
529 addresses.
530 */
531 void* dispatch;
532 }
533 VexTranslateArgs;
534
535
536extern
537VexTranslateResult LibVEX_Translate ( VexTranslateArgs* );
538
sewardjc24824a2005-07-07 13:52:03 +0000539/* A subtlety re interaction between self-checking translations and
540 bb-chasing. The supplied chase_into_ok function should say NO
541 (False) when presented with any address for which you might want to
542 make a self-checking translation.
543
544 If it doesn't do that, you may end up with Vex chasing from BB #1
545 to BB #2 (fine); but if you wanted checking for #2 and not #1, that
546 would not be the result. Therefore chase_into_ok should disallow
547 following into #2. That will force the caller to eventually
548 request a new translation starting at #2, at which point Vex will
549 correctly observe the make-a-self-check flag. */
550
sewardjac9af022004-07-05 01:15:34 +0000551
sewardjd887b862005-01-17 18:34:34 +0000552/*-------------------------------------------------------*/
553/*--- Show accumulated statistics ---*/
554/*-------------------------------------------------------*/
sewardjac9af022004-07-05 01:15:34 +0000555
sewardj887a11a2004-07-05 17:26:47 +0000556extern void LibVEX_ShowStats ( void );
sewardjac9af022004-07-05 01:15:34 +0000557
558
sewardjd887b862005-01-17 18:34:34 +0000559/*-------------------------------------------------------*/
560/*--- Notes ---*/
561/*-------------------------------------------------------*/
sewardj812a8582005-01-13 16:33:19 +0000562
563/* Code generation conventions that need to be recorded somewhere.
564 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
565
566 x86
567 ~~~
sewardj17c7f952005-12-15 14:02:34 +0000568 Generated code should be entered using a JMP instruction. On
sewardj812a8582005-01-13 16:33:19 +0000569 entry, %ebp should point to the guest state, and %esp should be a
570 valid stack pointer. The generated code may change %eax, %ebx,
571 %ecx, %edx, %esi, %edi, all the FP registers and control state, and
572 all the XMM registers.
573
sewardj6915b972005-01-13 16:36:42 +0000574 On entry, the FPU control word should be set to 0x027F, and the SSE
sewardj812a8582005-01-13 16:33:19 +0000575 control word (%mxcsr) should be set to 0x1F80. On exit, they
576 should still have those values (after masking off the lowest 6 bits
577 of %mxcsr). If they don't, there is a bug in VEX-generated code.
578
sewardj17c7f952005-12-15 14:02:34 +0000579 Generated code returns to the scheduler using a JMP instruction, to
580 the address specified in the .dispatch field of VexTranslateArgs.
sewardj812a8582005-01-13 16:33:19 +0000581 %eax (or %eax:%edx, if simulating a 64-bit target) will contain the
sewardj17c7f952005-12-15 14:02:34 +0000582 guest address of the next block to execute. %ebp may be changed
583 to a VEX_TRC_ value, otherwise it should be as it was at entry.
sewardj812a8582005-01-13 16:33:19 +0000584
585 CRITICAL ISSUES in x86 code generation. The only known critical
586 issue is that the host FPU and SSE state is not properly saved
587 across calls to helper functions. If any helper references any
588 such state, it is likely (1) to misbehave itself, since the FP
589 stack tags will not be as expected, and (2) after returning to
590 generated code, the generated code is likely to go wrong. This
591 really should be fixed.
sewardjdb4738a2005-07-07 01:32:16 +0000592
sewardj17c7f952005-12-15 14:02:34 +0000593 amd64
594 ~~~~~
595 Analogous to x86.
596
597 ppc32
598 ~~~~~
599 On entry, guest state pointer is r31. .dispatch must be NULL.
600 Control is returned with a branch to the link register. Generated
601 code will not change lr. At return, r3 holds the next guest addr
602 (or r3:r4 ?). r31 may be may be changed to a VEX_TRC_ value,
603 otherwise it should be as it was at entry.
604
605 ppc64
606 ~~~~~
cerion5b2325f2005-12-23 00:55:09 +0000607 Same as ppc32.
sewardj17c7f952005-12-15 14:02:34 +0000608
sewardjdb4738a2005-07-07 01:32:16 +0000609 ALL GUEST ARCHITECTURES
610 ~~~~~~~~~~~~~~~~~~~~~~~
sewardjce02aa72006-01-12 12:27:58 +0000611 The guest state must contain two pseudo-registers, guest_TISTART
sewardjdb4738a2005-07-07 01:32:16 +0000612 and guest_TILEN. These are used to pass the address of areas of
613 guest code, translations of which are to be invalidated, back to
614 the despatcher. Both pseudo-regs must have size equal to the guest
615 word size.
sewardjce02aa72006-01-12 12:27:58 +0000616
617 The architecture must a third pseudo-register, guest_NRADDR, also
618 guest-word-sized. This is used to record the unredirected guest
619 address at the start of a translation whose start has been
620 redirected. By reading this pseudo-register shortly afterwards,
621 the translation can find out what the corresponding no-redirection
622 address was. Note, this is only set for wrap-style redirects, not
623 for replace-style ones.
sewardj812a8582005-01-13 16:33:19 +0000624*/
sewardj887a11a2004-07-05 17:26:47 +0000625#endif /* ndef __LIBVEX_H */
sewardjac9af022004-07-05 01:15:34 +0000626
627/*---------------------------------------------------------------*/
sewardj887a11a2004-07-05 17:26:47 +0000628/*--- libvex.h ---*/
sewardjac9af022004-07-05 01:15:34 +0000629/*---------------------------------------------------------------*/