You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a key feature to make it easier to write clients.
This was PR 200203.
If the library is linked statically and has all of its calls to other
libraries and system calls wrapped (and those calls do not interact with
other user-mode resources) then it should be safe to use.
We already provide __wrap_malloc, __wrap_realloc, and __wrap_free so
clients can easily use ld's -wrap feature to override malloc, realloc, and
free at link time. In practice this may be sufficient for many libraries,
though there are no guarantees unless we wrap all calls to libc and all raw
system calls.
There are still issues with easily creating a version of STL libraries that
are PIC but static. It would be nice if we provided instructions for how
to do so, since the provided static libraries on more modern Linux distros
do not work properly. We got this to work only on a 32-bit system with
provided libraries (see api/docs/intro.dox sec_extlibs); on other systems
we either hit link-time or run-time errors.
Xref http://www.govirtual.org/message/1110 There are also issues with STL libraries making system calls that hit our
vsyscall hook (I put in a debug build check that then suggests
-sysenter_is_int80 as a workaround) or bypass our handling.
It would also be nice to have STL support on Windows.
We may want to share a partial solution with issue #46 and issue #47 :
on Windows we forward a number of common libc routines to ntdll.dll
(PR 219380) and it would be nice to have something similar on Linux but backed by
private libc routines (we would probably shift Windows to use the same routines).
we may want to provide a C++ allocator that calls DR mem alloc for passing to
all STL constructors, as an alternative to the default allocator and --wrap
on Windows, the private loader ( issue #157 ) is already allowing static or shared C/C++ library use and redirects memory allocation
From [email protected] on February 19, 2009 13:52:10
This is a key feature to make it easier to write clients.
This was PR 200203.
If the library is linked statically and has all of its calls to other
libraries and system calls wrapped (and those calls do not interact with
other user-mode resources) then it should be safe to use.
We already provide __wrap_malloc, __wrap_realloc, and __wrap_free so
clients can easily use ld's -wrap feature to override malloc, realloc, and
free at link time. In practice this may be sufficient for many libraries,
though there are no guarantees unless we wrap all calls to libc and all raw
system calls.
There are still issues with easily creating a version of STL libraries that
are PIC but static. It would be nice if we provided instructions for how
to do so, since the provided static libraries on more modern Linux distros
do not work properly. We got this to work only on a 32-bit system with
provided libraries (see api/docs/intro.dox sec_extlibs); on other systems
we either hit link-time or run-time errors.
Xref http://www.govirtual.org/message/1110 There are also issues with STL libraries making system calls that hit our
vsyscall hook (I put in a debug build check that then suggests
-sysenter_is_int80 as a workaround) or bypass our handling.
It would also be nice to have STL support on Windows.
Original issue: http://code.google.com/p/dynamorio/issues/detail?id=30
The text was updated successfully, but these errors were encountered: