Affix
view release on metacpan or search on metacpan
dyncall/ToDo view on Meta::CPAN
1.5:
----
- test atpcs thumb on arm and verify if ellipsis and C++ thiscalls work, if so adapt doc appendix
- test eabi thumb on arm and verify if ellipsis and C++ thiscalls work, if so adapt doc appendix
- new platform matrix
* check dark green cells and validate in general
- test/thunk win/x64 doesn't output anything decent for stack test (neither sigsegv nor output), which can create a problem for test log file as it'll mess with the subsequent test's output)
- remove test/gen-masm alltogether
- test code: add sparc tests for when out of register windows, meaning multiple layers deep in the call stack
- support platforms without shared libraries so they can be built by just typing `./configure;make` (e.g. minix < 3.2.1)
* also make sure minix with shared library support builds and works in general (>= 3.2.1) as well as ELF on Minix (>= 3.2.0) to begin with (as that's the base, and we only test on 3.1.8 so far)
- dyncallback's "stack_cleanup" can be removed from non x86 impls... test if they still work
- the CallVM-free functions are per VTable, however the latter can be changed out
at runtime... which basically changes potentially the deallocator...
dyncall/ToDo view on Meta::CPAN
- ellipsis (might be test itself, not respecting fixed part of args)
- callback_plain retval, see above under ARM
- callf
- support Solaris11 CFLAGS with -D_FILE_OFFSET_BITS=64
- make sure selinux works (esp. regarding NX bits)
Daniel has a patch for it, if needed, implementing allocwx with two memory blocks, one for w^x, mmaped to one for r|x
- support /SAFESEH on cl/win32
- test code functions should be in .so files, optionally, so the suites can directly be used to test dyncall bindings
- pkg-config support?
- add tests using alloca(), as this might depend on the frame pointer being correctly set (we don't
check for this, currently, at all - but might not affect dyncall's stubs, anyways) - verify
portasm:
--------
- add solaris support for x64
dyncall:
--------
- dyncall sparc v7/v8: -xO3 on SunPro segfaults in tests (observed years ago)
- callbacks and use of CC signature characters (only x86 has any support for different CCs for callbacks):
* support for arm (arm/thumb on same platform)
dyncall/doc/manual/callconvs/callconv_arm32.tex view on Meta::CPAN
\begin{figure}[h]
\begin{tabular}{5|3|1 1}
& \vdots & & \\
\hhline{~=~~}
register save area & \hspace{4cm} & & \mrrbrace{5}{caller's frame} \\
\hhline{~-~~}
local data & & & \\
\hhline{~-~~}
\mrlbrace{7}{parameter area} & last arg & \mrrbrace{3}{stack parameters} & \\
& \ldots & & \\
& 5th word of arg data @@@verify & & \\
\hhline{~=~~}
& r3 & \mrrbrace{4}{spill area (if needed)} & \mrrbrace{7}{current frame} \\
& r2 & & \\
& r1 & & \\
& r0 & & \\
\hhline{~-~~}
register save area (with return address) & & & \\ %fp points here to 1st word of this area: $\leftarrow$ fp
\hhline{~-~~}
local data & & & \\
\hhline{~-~~}
dyncall/doc/manual/callconvs/callconv_mips32.tex view on Meta::CPAN
\item Stack parameter order: right-to-left
\item Caller cleans up the stack
\item Caller is required to always leave a 16-byte spill area for \$a0-\$a3 at the end of {\bf its} frame, to be used and spilled to by the callee, if needed
\item The different stack areas (local data, register save area, parameter area) are each aligned to 8 bytes
\item generally, first four 32bit arguments are passed in registers \$a0-\$a3, respectively (only on hard-float targets: see below for exceptions if first arg is a float)
\item subsequent parameters are passed vie the stack
\item 64-bit params passed via registers are passed using either two registers (starting at an even register number, skipping an odd one if necessary), or via the stack using an 8-byte alignment
\item only on hard-float targets: if the very first call argument is a float, up to 2 floats or doubles can be passed via \$f12 and \$f14, respectively, for first and second argument
\item only on hard-float targets: if any arguments are passed via float registers, skip \$a0-\$a3 for subsequent arguments as if the values were passed via them
\item only on hard-float targets: note that if the first argument is not a float, but the second, it'll get passed via the \$a? registers
\item single precision float parameters (32 bit) are right-justified in their 8-byte slot on the stack on big endian targets, as they aren't promoted % @@@ verify
\item aggregates (struct, union) are passed as a sequence of words like integers, no matter the fields or if hard-float target (splitting across registers and stack is allowed)
\item {\it non-trivial} C++ aggregates (as defined by the language) of any size, are passed indirectly via a pointer to a copy of the aggregate
\end{itemize}
\paragraph{Return values}
\begin{itemize}
\item results are returned in \$v0 and \$v1, with \$v0 for all values \textless\ 64bit (only integer on hard-float targets)
\item only on hard-float targets: floating point results are returned in \$f0 (32-bit float), or \$f0 and \$f3 (64bit float)
\item aggregates (struct, union) are returned in a space allocated by the caller, with a pointer to it
dyncall/doc/manual/manual_epilog.tex view on Meta::CPAN
\subsection{Multi-threading}
The \product{dyncall} library is thread-safe and reentrant, by means that it
works correctly during execution of multiple threads if, and only if there is
at most a single thread pushing arguments to one CallVM. Since there's no
limitation on the number of created CallVM objects, it is recommended to keep a
copy per thread if mutliple threads make use of \product{dyncall} in parallel.
Invoking the call should always be thread-safe, however, whether the called
function is thread-safe is up to the programmer to verify, of course.
\subsection{Supported types}
Currently, the \product{dyncall} library supports all of ANSI C's integer,
floating point and pointer types as function call arguments and return values.
Additionally, C++'s \capi{bool} and C99's \capi{\_Bool} types are supported
across all supported platforms.
Due to the still rare and often incomplete support of the \capi{long double}
type on various platforms, the latter is currently not officially supported.
Also, \capi{\_Complex} is currently not supported.
dyncall/dyncall/dyncall_callvm_x64.c view on Meta::CPAN
#endif
/* --- syscall ------------------------------------------------------------- */
#if defined(DC_UNIX)
void dc_callvm_call_x64_syscall_sysv(DCCallVM* in_self, DCpointer target)
{
DCCallVM_x64* self;
/* syscalls can have up to 6 args, required to be "Only values of class INTEGER or class MEMORY" (from */
/* SysV manual), so we can use self->mRegData.i directly; verify this has space for at least 6 values, though. */
assert(numIntRegs >= 6);
self = (DCCallVM_x64*)in_self;
dcCall_x64_syscall_sysv(self->mRegData.i, target);
}
DCCallVM_vt gVT_x64_syscall_sysv =
{
&dc_callvm_free_x64
, &dc_callvm_reset_x64
dyncall/test/call_suite_aggrs/config.lua view on Meta::CPAN
--types = "Bcsijlpfd{}}}}}}<>>>>>"
-- user config for mk-cases.lua
-- if true, aggregates are copied via = operator, otherwise field by field
aggrcpsimple = true
-- if true, aggregate params are modified in called function, to test whether
-- they are passed "by value" (important for verifying by-value semantics for
-- callconvs where hidden pointers are used instead of real copies; aggregate
-- passing implementations must use of temporary copies in those cases)
aggrmutabletest = true
-- force aggregate packing, 0=off, pos values set fixed packing, neg values
-- set a random power-of-2 packing per aggregate, within [1,abs(aggrpacking)]
aggrpacking = 0
aggrpackingseed = seed
( run in 0.465 second using v1.01-cache-2.11-cpan-5467b0d2c73 )